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Foreword 



ETAPS 2000 was the third instance of the European Joint Conferences on Theory 
and Practice of Software. ETAPS is an annual federated conference that was 
established in 1998 by combining a number of existing and new conferences. 
This year it comprised five conferences (FOSSACS, EASE, ESOP, CC, TAG AS), 
five satellite workshops (CBS, CMCS, CoFI, GRATRA, INT), seven invited 
lectures, a panel discussion, and ten tutorials. 

The events that comprise ETAPS address various aspects of the system de- 
velopment process, including specification, design, implementation, analysis, and 
improvement. The languages, methodologies, and tools which support these ac- 
tivities are all well within its scope. Different blends of theory and practice are 
represented, with an inclination towards theory with a practical motivation on 
one hand and soundly-based practice on the other. Many of the issues involved 
in software design apply to systems in general, including hardware systems, and 
the emphasis on software is not intended to be exclusive. 

ETAPS is a loose confederation in which each event retains its own identity, 
with a separate program committee and independent proceedings. Its format is 
open-ended, allowing it to grow and evolve as time goes by. Contributed talks 
and system demonstrations are in synchronized parallel sessions, with invited 
lectures in plenary sessions. Two of the invited lectures are reserved for “uni- 
fying” talks on topics of interest to the whole range of ETAPS attendees. The 
aim of cramming all this activity into a single one-week meeting is to create a 
strong magnet for academic and industrial researchers working on topics within 
its scope, giving them the opportunity to learn about research in related areas, 
and thereby to foster new and existing links between work in areas that were for- 
merly addressed in separate meetings. The program of ETAPS 2000 included a 
public business meeting where participants had the opportunity to learn about 
the present and future organization of ETAPS and to express their opinions 
about what is bad, what is good, and what might be improved. 

ETAPS 2000 was hosted by the Technical University of Berlin and was effi- 
ciently organized by the following team: 

Bernd Mahr (General Chair) 

Hartmut Ehrig (Program Coordination) 

Peter Pepper (Organization) 

Stefan Jahnichen (Finances) 

Radu Popescu-Zeletin (Industrial Relations) 

with the assistance of BWO Marketing Service GmbH. The publicity was su- 
perbly handled by Doris Fahndrich of the TU Berlin with assistance from the 
ETAPS publicity chair, Andreas Podelski. Overall planning for ETAPS con- 
ferences is the responsibility of the ETAPS steering committee, whose current 
membership is: 




VI 



Foreword 



Egidio Astesiano (Genova), Jan Bergstra (Amsterdam), Pierpaolo Degano 
(Pisa), Hartmut Ehrig (Berlin), Jose Fiadeiro (Lisbon), Marie-Claude 
Gaudel (Paris), Susanne Graf (Grenoble), Furio Honsell (Udine), Heinrich 
HuBmann (Dresden), Stefan Jahnichen (Berlin), Paul Klint (Amsterdam), 
Tom Maibaum (London), Tiziana Margaria (Dortmund), Ugo Montanari 
(Pisa), Hanne Riis Nielson (Aarhus), Fernando Orejas (Barcelona), 
Andreas Podelski (Saarbriicken), David Sands (Goteborg), Don Sannella 
(Edinburgh), Gert Smolka (Saarbriicken), Bernhard Steffen (Dortmund), 
Wolfgang Thomas (Aachen), Jerzy Tiuryn (Warsaw), David Watt (Glas- 
gow), Reinhard Wilhelm (Saarbriicken) 

ETAPS 2000 received generous sponsorship from: 

the Institute for Gommunication and Software Technology of TU Berlin 
the European Association for Programming Languages and Systems 
the European Association for Theoretical Gomputer Science 
the European Association for Software Development Science 
the “High-Level Scientific Gonferences” component of the European 
Gommission’s Fifth Framework Programme 

I would like to express my sincere gratitude to all of these people and organiza- 
tions, the program committee members of the ETAPS conferences, the organizers 
of the satellite events, the speakers themselves, and finally Springer- Verlag for 
agreeing to publish the ETAPS proceedings. 
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Donald Sannella 
ETAPS Steering Gommittee Ghairman 




Preface 



This volume contains the proceedings of the 6th TACAS, International Confer- 
ence on Tools and Algorithms for the Construction and Analysis of Systems. 
TACAS took place at the Technical University of Berlin, March 27-31, 2000, as 
a part of the third European Joint Conferences on Theory and Practice of Soft- 
ware (ETAPS) whose aims and organization are detailed in a separate foreword 
by Don Sannella. 

Previous TACAS meetings were held in 1999 (Amsterdam), 1998 (Lisbon), 
1997 (Twente), 1996 (Passau), and 1995 (Aarhus). Since 1998 TACAS has been 
a conference and part of ETAPS. All previous TACAS proceedings have been 
published as volumes in Springerr-Verlag’s Lecture Notes in Computer Science 
series. 

It is the goal of TACAS to provide a forum for researchers, developers, and 
users interested in the development and application of tools for the specifica- 
tion, verification, analysis, and construction of software and hardware systems. 
In particular, it aims to promote the exchange of ideas between different commu- 
nities of theoreticians, tool builders, tool users, and system designers of various 
specialized areas that traditionally had little interaction. In this respect, TACAS 
reflects the overall goal of ETAPS from a tool oriented perspective. In effect, the 
scope of TACAS intersects with those of all other ETAPS events, which address 
more traditional areas of interest. 

As a consequence, in addition to the standard criteria for acceptability, con- 
tributions have also been selected on the basis of their conceptual significance in 
the neighbouring areas. This comprises the comparison of concepts and methods, 
their degree of support via interactive or fully automatic tools, and case studies 
revealing the application profiles of the considered methods and tools. 

In order to emphasize the practical importance of tools, TACAS encourages 
tool presentations on equal footing with traditional scientific papers, treating 
them as “first class citizens”. In practice, this means that they have the same 
space in the proceedings and a full slot in the plenary conference session. Of 
course, during the conference there were also demonstrations of tools not an- 
nounced in the official program. 

These proceedings contain 

— an invited lecture by Pierre Wolper and Bernhard Boigelot from the Uni- 
versity of Liege “On the Construction of Automata from Linear Arithmetic 
Constraints'^ . 

— 33 regular contributions, covering a wide range of topics and being all 
relevant to the development of tools. They have been selected from 107 
submissions, which is the largest number of submission TACAS has had so 
far. 

— the text of two short tool demonstrations which were reviewed by the 
ETAPS steering committee. 




VIII Preface 



TACAS was hosted by the Technical University of Berlin, and being part of 
ETAPS, it shared the excellent organization described by Don Sannella in the 
foreword. TACAS will be continued next year as a part of ETAPS at Genova 
and in 2002 in Grenoble. 

Finally, we would like to thank the program committee and all the referees for 
their assistance in selecting the papers, Don Sannella for mastering the coor- 
dination of the whole ETAPS, and last but not least, the local organizers in 
Berlin. 

January 2000 Susanne Graf 

Michael Schwartzbach 
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On the Construction of Automata from Linear 
Arithmetic Constraints* 



Pierre Wolper and Bernard Boigelot 



Universite de Liege, Institut Montefiore, B28 
4000 Liege Sart-Tilman, Belgium 
{pw,boigelot}@montef lore .ulg. ac . be 



Abstract. This paper presents an overview of algorithms for construct- 
ing automata from linear arithmetic constraints. It identifies one case in 
which the special structure of the automata that are constructed allows a 
linear-time determinization procedure to be used. Furthermore, it shows 
through theoretical analysis and experiments that the special structure 
of the constructed automata does, in quite a general way, render the 
usual upper bounds on automata operations vastly overpessimistic. 



1 Introduction 

Model checking [CES86,QS81,VW86] is a now widespread technique for verifying 
temporal properties of reactive programs. There are several ways to develop 
the theory of model checking, a particularly attractive one being through the 
construction of automata from temporal logic formulas [VW86,BVW94]. As a 
result, there has been a fair amount of interest in the construction of automata 
from temporal logical formulas, the history of which is actually fairly interesting. 

The starting point is clearly the work of Biichi on the decidability of the 
first and second-order monadic theories of one successor [Biic62]. These decid- 
ability results were obtained through a translation to infinite-word automata, 
for which Biichi had to prove a very nontrivial complementation lemma. The 
translation is nonelementary, but this is the best that can be done. It is quite 
obvious that linear-time temporal logic can be translated to the first-order the- 
ory of one successor and hence to infinite-word automata. From a logician’s 
point of view, this could be seen as settling the question, but an interest in 
using temporal logic for computer science applications, in particular program 
synthesis [MW84,EC82] triggered a second look at the problem. Indeed, it was 
quite obvious that a nonelementary construction was not necessary to build an 
automaton from a temporal logic formula; it could be done within a single ex- 
ponential by a direct construction [WVS83,VW94]. As originally presented, this 
construction was worst and best case exponential. Though it was fairly clear 
that it could be modified to operate more effectively on many instances, nothing 

* This research was partially funded by a grant of the “Communaute frangaise de 
Belgiqne - Direction de la recherche scientifique - Actions de recherche concertees” . 
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was written about this, probably because the topic was thought to be rather 
trivial and had no bearing on general complexity results. 

Nevertheless, the idea that doing model checking through the construction of 
automata was taken seriously, at least by some, and attempts were made to incor- 
porate automata-theoretic model checking into tools, notably into 
SPIN [Hol91,Hol97]. Of course, this required an effective implementation of 
the logic to automaton translation algorithm and the pragmatics of doing this 
are not entirely obvious. A description of such an implementation was given 
in [GPVW95] and “improved” algorithms have been proposed since [DGV99]. 
Note that there are some questions about how to measure such “improvements” 
since the worst-case complexity of the algorithms stays the same. Nevertheless, 
experiments show that, for the temporal logic formulas most frequently used in 
verification, the automata can be kept quite small. Thus, even though it is an 
intrinsically exponential process, building an automaton from a temporal logic 
formula appears to be perfectly feasible in practice. What is surprising is that 
it took quite a long time for the details of a usable algorithmic solution to be 
developed and codified. 

Since building automata from temporal logic formulas turns out to be fea- 
sible, one might wonder if the same approach could work for other logics. This 
has been tried for the second-order monadic logic of one successor (SIS) in the 
MONA tool [H.JJ+95]. Here, one is confronted with nonelementary complexity, 
but careful algorithm selection and coding as well as the fact that the prac- 
tically useful formulas are not arbitrary make the tool unquestionably usable. 
Motivated by the need to represent sets of integer vectors in the context of the 
verification of infinite-state systems [BW94], an automata-based approach is be- 
ing developed for linear integer (Presburger) arithmetic [WB95,Boi98]. The idea 
that Presburger arithmetic formulas can be represented by automata goes back 
at least to Biichi [Biic60], and has lead to nice characterization results for the 
finite-state representable sets of integer vectors [Gob69,Scm77,BHMV94]. The 
attractiveness of the approach is not so much for single-shot arithmetic decision 
problems for which more traditional decision procedures perform well [Pug92], 
but for situations in which represented sets are repeatedly manipulated and 
compared, as is necessary in verification. Indeed, minimized deterministic finite 
automata are a convenient normal form for arithmetic formulas, in a way similar 
to BDDs [Bry92] being a normal form for Boolean formulas. 

Nevertheless, attempts to make a pragmatic use of automata representing 
arithmetic formulas are fairly recent [WB95,BG96] and one now needs to delve 
into the details of the automata constructions. Indeed, a straightforward ap- 
proach to building the automata is quite unworkable and a crude complexity 
analysis leads only to a nonelementary upper bound, which is unsatisfactory 
since Presburger arithmetic is know to be decidable in double exponential space. 
Fortunately, one can do better. In [WB95] it was suggested to use concurrent 
automata as a representation. This indeed reduces the size of the automata, but 
pushes up the complexity of manipulating them. An important step was made 
in [BG96] where it was showed that there is a simple construction for obtain- 
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ing a deterministic automaton corresponding to an equation or an inequation. 
That paper even goes further and claims that a triple exponential determinis- 
tic automaton can be built for an arbitrary Presburger formula. Unfortunately, 
though the result itself might not be false, the argument used to substantiate 
this claim is intrinsically incorrect as we will discuss in this paper. In [TRS98] an 
encouraging experiment with an automaton-based Presburger implementation is 
described. Finally, the LASH tool [LASH] is a comprehensive implementation of 
arithmetic through automata. 

This paper aims at presenting and improving on the basics of the pragmatics 
of constructing automata from Presburger formulas. It starts with a detailed 
exposition of the construction of automata for linear equations and inequations. 
The fundamental idea of the construction is that of [BC96] , which we extend and 
improve. First, we deal with signed integers using 2’s complement notation (see 
also [BBR97,BRW98]). Second, we aim at obtaining automata for both direc- 
tions of reading number encodings. For equations, this is not problematic since 
the constructed automaton is immediately deterministic in both directions. For 
inequations, the construction of [BC96] gives an automaton that is deterministic 
in one direction, but nondeterministic in the other. However, we show that the 
automaton, taken in its nondeterministic direction, has a special structure that 
allows the use of a linear-time determinization procedure of possibly indepen- 
dent interest. Furthermore, this result shows that at least in this special case, 
the general exponential upper bound on determinization is vastly pessimistic. 

Finally, we turn to the problem of building automata for arbitrary Presburger 
formulas. Here, the interesting question is whether an unbounded alternation of 
quantifiers leads or not to a nonelementary blowup in the size of the automaton. 
This of course can be the case for arbitrary automata, but we show, with the 
help of a logic-based argument, that it is not the case for the automata obtained 
from Presburger formulas. We further substantiate this by giving the results of 
a number of experiments done with the LASH tool. 

2 Preliminaries 

Presburger arithmetic is the first-order theory of the structure (N, 0, <,+), he. 
the natural numbers with the < predicate as well as the 0-ary function 0 and the 
binary function -I-, all interpreted in the standard way. A Presburger formula 
with free variables thus represents a set of natural number vectors. In what 
follows, we will also refer to the theory of the related structure (Z, 0, <, -I-), i.e. 
the additive theory of the integers, as Presburger arithmetic. Context will remove 
any ambiguity. 

When encoded in a base r > 2, a natural number is a word over the alphabet 
{0,...r— 1}.A language or set of words thus represents a set of natural numbers. 
An obvious question to ask then is which sets of natural numbers correspond to 
the regular languages under this representation. The question was answered by 
Cobham who showed that the sets representable in at least two relatively prime 
bases are exactly those definable in Presburger arithmetic [Cob69] . If one limits 
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oneself to a specific base, say base 2, slightly more is representable. Precisely, one 
can add to Presburger arithmetic the function Vr (n) giving the largest power of 
the base r dividing its argument n (see [BHMV94]). 

Similar results exist for vectors of natural numbers. To encode an n-dimen- 
sional vector x = (xi, . . . ,Xn), one encodes each of its components in base r. 
The length of the encoding of the components is then made uniform by adding 
leading Os to the shorter components. The result is then viewed as a word over the 
alphabet r” by considering together the first digits of all the vector components, 
then the second digits, and so on. 

Example 1. The vector (4, 3) is encoded in binary by (100, Oil), which is viewed 
as the word (1, 0)(0, 1)(0, 1) over the alphabet 2^. 

Cobham’s result on the sets representable by regular languages was extended to 
natural number vectors by Semenov [Scm77]. 

In many situations, it is useful to deal with integers rather than with natural 
numbers. There are several ways to extend the encoding we just introduced 
to integers. An obvious one is to add a sign bit, but this leads to the need to 
constantly distinguish the cases of positive and negative numbers. If one works in 
base 2, which will be our choice from now on, things can be made more uniform, 
exactly as is done in computer arithmetic, by using 2’s complement notation as 
proposed in [WB95,BRW98,Boi98]. 

In this notation, a number b^bk-i ■ ■ ■ bibo of length k + 1 written in base 2 is 
interpreted as + J2o<i<k-i ^*2*. It is thus positive if bk is 0 and negative if 
this bit is 1 . There is one slight difficulty that comes from the fact that there is no 
bound on the size of the integers we consider and that thus we are dealing with 
variable-length encodings of integers, as opposed to the fixed length usually used 
in computer arithmetic. This is not problematic if we require that the leading bit 
of a number is always a sign bit, i.e. it is 0 is the number is positive and 1 if the 
number is negative^. Indeed, there is then no ambiguity on the interpretation of 
the first bit of a number and repeating the sign bit, whether it is 0 or I, has no 
incidence on the value of the number interpreted according to 2’s complement’s 
rule since —2^ -|- 2^“^ = —2^“^. We can thus still easily make the lengths of the 
encodings of the components of a vector equal. 

Example 2. The vector (—2, 12) can be encoded as (IIIIO, 01100) or as the word 

( 1 , 0 )( 1 , 1 )( 1 , 1 )( 1 , 0 )( 0 , 0 ). 

Our goal here is to use finite automata to represent Presburger definable sets 
of integers. The advantages of this representation are that it is easy to com- 
pute with and that it makes questions about the represented sets, for instance 
nonemptiness, easy to decide. Furthermore, by using minimal deterministic au- 
tomata, one even obtains a convenient normal form for Presburger definable sets 
of integer vectors. We will thus consider the problem of building automata cor- 
responding to Presburger formulas. There are however two questions we have to 
deal with before doing so. 

^ More formally, this means that to represent an integer x, we use a number of bits 
k > 0 large enough to satisfy —2*’“^ < x < 2*’“^. 
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Since sign bits can be repeated any number of times, an integer vector has an 
infinite number of representations. The question then is, which representations 
should the automata accept. It turns out that the most convenient answer is all 
valid representations, a representation of a vector being valid if its length is suf- 
ficient to allow its largest magnitude component to start with a sign bit. Indeed, 
representing an integer vector by all its encodings allows the Boolean operations 
on sets of vectors to correspond exactly with the matching language operation 
on the encodings. The same is unfortunately not true of projection, which is 
the automaton operation that allows us to handle existential quantification. In- 
deed, if for example one projects out the largest component of a vector by using 
language projection on the encodings, one can be left with an automaton that 
accepts only encodings beyond an unnecessarily long minimum inherited from 
the component that was eliminated. This problem can nevertheless be solved by 
using a specific projection operation that allows skipping the repetition of the 
initial symbol of a word. 

The second question is whether our automata will read encodings starting 
with the most significant or with the least significant bit. One can see advantages 
to using either directions, and the constructions we give allow automata to be 
built for either direction. However, our default choice, and the one we will use in 
examples, is to start with the most significant bit, this order often making the 
search for a vector accepted by an automaton more effective. 



3 Building Automata for Presburger Formulas 

We now turn to the problem of building an automaton accepting all encod- 
ings of the elements of a set defined by a Presburger formula. We could begin 
with a construction of automata for addition, equality and inequality, but there 
are interesting constructions that can deal directly with linear equations and 
inequations. We thus start with these. 



3.1 Building Automata for Equations 

The construction we present here is in essentially the one given in [BC96] 
adapted to handle negative numbers represented using 2’s complement, as well 
as to reading numbers starting with the most significant bit first. The construc- 
tion is based on the following simple observation. Consider a representation of 
a vector x = {x\, . . . ,Xn) that is k bits long, and imagine adding the bits^ 
(6i, . . . , bn) = b respectively to the encodings of {x\, . . . , x„). The value x' of 
the (fc -I- l)-bit long encoding thus obtained is given by x' = 2x -f b where addi- 
tion is component- wise. This rule holds for every bit-tuple added except for the 

^ Note that since there is a unique integer vector corresponding to an encoding, we 
will quite liberally talk about the vector defined by an encoding and, when appro- 
priate use vector notation for encodings. In particular, we will always write elements 
(6i, . . . , hn) of 2” as bit vectors b. 
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first one, in which Is have to be interpreted as —1. Thus, the value of a one bit 
long vector (6i, . . . , 6„) = b is simply — b. 

Given this, it is very simple to construct an automaton for a linear equa- 
tion aiXi -I- • • • -I- UnXn = c which we write a.x = c. Indeed, the idea is to keep 
track of the value of the left-hand side of the equation as successive bits are 
read. Thus, except for a special initial state, each state of the automaton cor- 
responds to an integer that represents the current value of the left-hand side. 
From a state corresponding to an integer 7 = a.x for the vector x that has been 
read so far, there is a single transition for each bit vector b leading to the state 
7 ' = a.( 2 x-|-b) = 2 a.x-f a.b = 27-t-a.b. From the special initial state, the tran- 
sition labeled b simply leads to the state a.(— b). The only accepting state is the 
one whose value is c. Formally, the automaton corresponding to an n-variable 
equation a.x = c is A = (S,2^, S, Si, c) where 

— S = ZU {si}, i.e. the states are the integers plus a special state s^; 

— the alphabet 2 ” is the set of n-bit vectors; 

— the transition function S is defined by 

• (5(si,b) = —a.b and 

• S{j, b) = 27 -b a.b, for 7 yf s*; 

— the initial state is the special state s^; 

— the only accepting state is c, the value of the right-hand side of the equation. 

As defined, the automaton is infinite, but there are only a finite number of states 
from which the accepting state is reachable. Indeed, if ||a||i represents the norm 
of a vector a = (oi, . . . , a„) defined by ||a|ji = have that from any 

state 7 such that I7I > ||a||i, any transition leads to a state 7' with \^'\ > |7|. 
So, if furthermore I 7 I > |c|, c can never be reached from such a state. Hence, 
all states 7 such that I7I > ||a||i and I7I > |c| can be collapsed into a single 
nonaccepting state. 

Example 3. The automaton for the equation x — y = 2\s, given in Figure 2. Note 
that, according to the criterion we have just given, the states beyond the solid 
line cannot be reached from the accepting state and thus can be collapsed into a 
single nonaccepting state. Furthermore, looking more carefully at this particular 
automaton, one sees that the states to be collapsed can in fact include those 
beyond the dotted line. 

The rule we have given for identifying unnecessary states is only approxima- 
tive. It can be refined, but a more effective approach of identifying the necessary 
states is actually to construct the automaton backwards, starting from the ac- 
cepting state. If this construction is limited to reachable states, only necessary 
states will be constructed. The exact construction is given in Figure 2. 

When limited to its reachable states, the automaton obtained by this con- 
struction is exactly the useful part of the automaton given by the forward con- 
struction. One can complete it by directing all missing transitions to a single 
nonaccepting sink state. It is deterministic since it is a part of the forward au- 
tomaton we constructed initially and furthermore, it is minimal, since the sets 
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1 . Create a table H of automata states and a list L of “active” states. Both are 
initialized to {c}. 

2 . Repeat the following step until L = 0 . 

3. Remove a state 7 from L, and for every b £ 2": 

— If 7o = (7 — a.b) /2 is an integer, then 

• If 7o is not in H , add it to H and L; 

• Add a transition labeled b from 70 to 7; 

— If 7 = —a.b, then 

• Add a transition labeled by b from the initial state Si to 7. 



Fig. 2. The automaton construction algorithm for an equation. 
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of words accepted from two distinct states cannot be identical. Indeed, the au- 
tomaton is also deterministic when going backwards, except for transitions from 
the initial state, which is not a problem since the language accepted from the 
initial state is never equal to the one accepted from any other state. How many 
states does the automaton have? Clearly, any state (except for the initial one) is 
obtained from c by repeatedly applying the transformation T(7) = (7 — a.b)/2. 
The states obtained by applying this transformation i times, i.e. those in T*(c) 
are in the range 

H^lli 

2 » 23 



which is always included in 




( 1 ) 



Equation ( 1 ), implies that for i > log2 c, the range reduces to [— |ja||i, ||a||i]. 
Thus the states can be found in at most log2 c -I- 1 ranges each of size bounded 
by 2||a||i -|- 1 . The total number of constructed states is thus 0(log2 c x ||a||i), 
which is only logarithmic in the value of the additive constant c and hence linear 
in its number of bits. 



3.2 Building Automata for Inequations 

Consider now an inequation a.x < c. Note that since we are dealing with integers, 
a strict inequation a.x < c is equivalent to the nonstrict inequation a.x < c — 1 . 
The forward construction we gave in the previous section can still be used to 
build an automaton for the inequation, the only difference being that now the 
set of accepting states is the set E = {7 | 7 < c}. Again, the automaton can be 
limited to a finite number of states. Indeed, starting with a positive 7 such that 
7 > |ja||i, all transitions will lead to a 7' > 7 and hence if 7 > c, the inequation 
will never be satisfied. Similarly, if 7 is negative and —7 > ||a||i, all transitions 
will always lead to a 7' < 7 and thus if 7 < c, the inequation is satisfied. 

Again, the analysis above is somewhat coarse and a backwards construction 
can yield an automaton with less states. However, we have to take into account 
the fact that we are dealing with an inequation and not an equation, which leads 
us to construct an automaton somewhat different from the forward automaton. 
The main point is that, when computing the transitions leading to a state 7, we 
can no longer dismiss transitions for which 7 o = (7 ~ a.b)/2 is not an integer. 
Indeed, interpreting the fact that a state 7 is reached to mean that the inequation 
a.x < 7 is satisfied by the word x read so far, the condition that has to be satisfied 
in a state 70 from which 7 is reached by a b transition is 7o < (7 — a.b)/2. An 
infinite number of states satisfy this condition, but it is sufficient to keep the 
largest since it corresponds to the weakest condition. Thus, as origin of a b 
transition to a state 7, we choose 70 = [(7 — a.b) /2J . Finally, we have to add 
the possibility of transitions originating in the initial state. Thus, if —a.b < 7, 
we also add a b transition from the initial state to 7. 
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The exact construction of the automaton is given in Figure 3 , the initial state 
being Si and the accepting state being c. 



1 . Create a table H of automata states and a list L of “active” states. Both are 
initialized to {c}; 

2 . Repeat the following step until L = 0 : 

3 . Remove a state 7 from L, and for every b G 2 ”': 

— Let 7o = [(7 — a.b)/ 2 j, then 

• If 7o is not in H, add it to H and L; 

• Add a transition labeled b from 70 to 7; 

— If — a.b < 7, then 

• Add a transition labeled by b from the initial state Si to 7. 

Fig. 3 . The automaton construction algorithm for an inequation 



As opposed to the case of equations, the automaton we have just built is 
quite different from our initial forward automaton and is no longer determinis- 
tic. Indeed, clearly transitions from the initial state are not deterministic and, 
furthermore, [(7 — a.b)/2j can be the same for two different values of 7, just 
think of 7 = 2 and 7 = 8 with b = 0 . The bound on the number of states we 
derived for the case equations still holds, but for a nondeterministic automaton. 
If a deterministic automaton is desired, one is now faced with a potentially ex- 
ponential determinization cost. However, it would be quite surprising that the 
automaton for an inequation be so much bigger than the automaton for the cor- 
responding equation. We show that this is not case since the automaton we have 
constructed has a special structure that allows it to be determinized without 
increasing its number of states. 

The intuition behind the efficient determinization procedure is the following. 
Suppose that from a state 7, one has two b transitions leading respectively to 
states 7i and 72 . One obviously has either 71 < 72 or 72 < 71 and one can assume 
without loss of generality that the former holds. If one reads being in a state 7 
as meaning that the inequation a.x < 7 is satisfied by what has been read so far, 
it is immediate that any x that satisfies a.x < 71 also satisfies a.x < 72. Hence 
only the stronger of the two conditions, i.e. a.x < 71 needs to be remembered 
in order to know if the word being read will end up being accepted, and the 
transition to the state 72 can be dropped. We now formalize this intuition. 

Definition 1. Given a nondeterministic finite automaton A = (S', A, < 5 , sq, F), 
let As he the automaton A = (S, A, ( 5 , s, F), i.e. A where the initial state is s. 
The automaton A is then said to be ordered if there is an explicitly given, i.e. 
constant-time decidable, strict total order -< on its set S (possibly excluding the 
initial state if no transitions lead to it) of states and if for any pair of states 
satisfying si ^ S2, we have that F(Asj) C L^As^). 

Ordered automata can be determinized efficiently. 
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Lemma 1. A nondeterministic ordered finite automaton ean he determinized in 
linear time. 

Proof. Let A = (S, E, S, sq, F) be an ordered nondeterministic finite automaton, 
i.e its transition function is of the type 6 : S x E ^ 2 ^ . The corresponding 
deterministic automaton is A = (S, E,S' , sq, F), all components of which are 
identical to those of A, except for S' : S x E ^ S which is defined by 

S'(a, s) = max(S(a, s)). 

Thus, if several identically labeled transitions leave a state, they are replaced 
by a single transition to the largest of these states in the order defined on S. 
According to the definition of ordered automata, the language accepted from 
this largest state includes the language accepted from all smaller states and 
hence removing the transitions to smaller states does not change the language 
accepted by the automaton. Also note that if the initial state is not the target 
of any transition, it can safely be left out of the order. The determinization 
procedure just amounts to removing transitions and can be easily implemented 
in linear time. □ 

We are aiming at applying Lemma 1 to the nondeterministic automata we 
have constructed for inequations. So we need to check if these automata are 
ordered. Let us look at the words accepted from a state 7 of the automaton A 
constructed for an inequation a.x < c. These, will all be words w encoding 
a vector x^,, which suffixed to any word wg encoding a vector satisfying 
a.Xmj, < 7 form a word wqw encoding a vector that satisfies a.Xwow E c. 

Thus all the words w accepted from a state 7 are such that for all wg satisfying 
a.Xmj, < 7 one has 

a.x^o^ = + a.x^, < c 

and hence, since the above holds for any wg such that a.Xmg < "f, w must satisfy 

^ 2 l^ngth{w) (2) 

So, one expects that, if 71 < 72, a word w accepted from 72 will also be ac- 
cepted from 71. In other words, one expects that L{A.y^) C L(Ajg) and that the 
automaton is ordered with respect to the relation ^ which is the inverse of the 
numerical order. However, this is not quite so. Indeed, even though all words 
accepted from a state 7 satisfy the relation expressed by Equation (2), it is not 
the case that all words satisfying Equation (2) are accepted. Fortunately, it is 
possible to “complete” the automaton we have constructed in such a way that 
the words accepted from a state 7 are exactly those defined by Equation (2), 
and this can be done without adding states to the automaton. 

The completion procedure just adds transitions and accepting states. Given 
the automaton A = (5, 2”, S, Si, c) constructed by the algorithm of Figure 3 for 
an inequation a.x < c, it constructs an automaton A' = (S', 2”, i5', Si, E') as 
described in Figure 4. 
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1. The set of accepting states is -F' = {7 G S' | 7 < c}; 

2 . For every state 7, and bit vector b G 2 ", <5'(7,b) = 5(7, b) U {7' G S | 7' > 

27 + a.b}. 



Fig. 4. The completion algorithm. 



The completion algorithm can add a number of transitions that is quadratic 
in the number of states and hence can require quadratic time. We will see how 
this can be improved, but first let us prove that the completion algorithm does 
produce an ordered automaton. 

Lemma 2. The completion algorithm of Figure 4 produces an ordered automa- 
ton that accepts the same language as the original automaton. 

Proof. The order with respect to which the completed automaton is ordered is 
the inverse of the numerical order. We thus have to prove that if 71 < 72 then 
L{A-y2) C L(A-y^). This is done by showing that the set of words accepted from 
any state 7 is exactly the one satisfying the relation given in Equation ( 2 ), which 
at the same time shows that the language accepted by the completed automaton 
is unchanged since the original automaton already accepted all solutions of the 
inequation. 

To show that any word satisfying Equation ( 2 ) in a state 7 is accepted from 
that state, we proceed by induction on the length of words. For the induction 
to go through, we strengthen the property we are proving with the fact that 
for any word w of length k, the state 7“^’' which is the largest 7 such that 
72^ + a. Xu, < c is in S. If the word is of length 0 (the empty word e), it must be 
accepted iff 7 < c. This is guaranteed by the definition of the set of accepting 
states F'. Furthermore, 7™*^’' is simply c, which by construction is in S. 

For the inductive step, let w = biwi, where wi is of length k — 1 . By inductive 
hypothesis, the state is in S. By construction, the state — a.bi)/2j 

is in S and is the state 7™*^’'. Since w satisfies the relation of Equation (2) in 7, 
one must have that 7 < Hence, the completion procedure adds from 7 a 

transition to 7™“ given that 

7“r>27r" + a.bi >27 + a.bi. 

Hence w is accepted from 7. □ 

Note that the completion procedure adds transitions that will later be re- 
moved by the determinization procedure for the ordered automaton that is ob- 
tained. In fact from a state 7 and for a bit vector b, the determinization proce- 
dure only keeps the transition to the smallest 7' such that 7' > 7 -I- a.b. Hence, 
in our completion procedure, we can add transitions according to the following 
rule: 

1. For every state 7, and bit vector b G 2”, ( 5 '( 7 ,b) = i 5 ( 7 ,b) U min{7' G S | 

7 ' > 27 -I- a.b}. 
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This can be done in linear time and we have the following result. 

Theorem 1. The automaton constructed for an inequation by the algorithm of 
Figure 3 can he determinized in linear time. 

Example 4- The automaton produced by Algorithm 3 for the inequation 
X — y < 2 is given in Figure 5, with the elements added by the simplified com- 
pletion procedure in boldface, and the transitions deleted by the determinization 
procedure underlined. 



00,01,10,11 




Fig. 5. The automaton for x — y <2. 



3.3 Building Automata for Arbitrary Formulas 

In an arbitrary Presburger formula, one can always move negations inwards and 
quantifications outwards. Doing so, one obtains a Boolean combination of linear 
(in)equations prefixed by a string of quantifiers, i.e. a formula of the form 

Q 1 X 1 Q 2 X 2 ■ ■ ■ QnXn4>{^lj- ■ .,Xn,yi, ■ ■ ■ , 2/m) (3) 

where each Qi is either V or 3, ()) is quantifier free and yi,. ■ .ym are the free 
variables of the formula. The quantifier-free formula ^ is a Boolean combination 
of linear equations and inequations <f>i. For each of the 4>i, we have seen how 
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to build a deterministic automaton of size where is the number 

of symbols needed to represent the (in)equation, coefficients being encoded in 
a base > 2. The Boolean combination of these (in)equations can thus be repre- 
sented by a deterministic automaton that is the product of the automata for the 
(in)equations, the accepting states being defined according to the given Boolean 

combination. This product is of size 0(Y[i or 0(2°^^ which is equal 

to 0(2'^l‘^l). The size of this deterministic automaton is thus at most a single 
exponential in the size of the formula. 

To handle quantification, one replaces V by and uses projection as 

the automaton operation corresponding to existential quantification. There is 
however one slight problem in doing so, which is that the automaton obtained 
by standard projection does not accept all encodings of the projected set of 
integer vectors. 

Example 5. The automaton for x = 1 f\y = A and the result of projecting out y 
from this automaton are given in Figure 6. The resulting automaton accepts the 
encodings of 1, but only those that are of length at least 4. The encodings 01 
and 001 are not accepted. 

00 

-o 





Fig. 6. Automata for a; = 1 A y = 4 and its projection. 



The problem illustrated in Example 5 can be solved by modifying the automa- 
ton obtained from projection to ensure that when a word in is accepted the 
word bw is also accepted. This is done by including in the set of states reachable 
from the initial state by b all states reachable from the initial state by b+. 

The automaton obtained after a projection step is in general nondeterministic 
and one needs to determinize it in order to apply the complementation needed 
to handle universal quantification. One thus expects a exponential blowup in 
the size of the automaton for each quantifier alternation and thus an automaton 
whose size grows in a nonelementary way. In [BC96] it is argued that this is 
not the case, and that the size of the automaton is at most 3 exponentials in 
the size of the formula. Unfortunately, the argument used is false. Indeed, it es- 
sentially amounts to translating the string of alternating quantifiers to Boolean 
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transitions, generalizing the translation to nondeterministic transitions done in 
the handling of projection. The result is thus an alternating automaton of size 
which can be converted into a deterministic automaton two exponen- 
tials larger. The catch is that this implies that the quantifier prefix is handled 
bit-wise rather than number- wise. Explicitly, when moving from numbers to bi- 
nary encodings, this implies that rather than translating (3) to 

Qlb\lbi2 . . . &lfcQ2&21^22 • ■ ■ &2fc ■ ■ • Qnbnlbn 2 ■ ■ ■ bnk 4 >^ 
one translates it to 

Qi^1iQ2^21 ■ ■ ■ QnbnlQlbl 2 Q 2 b 22 ■ ■ ■ Qnbn 2 ■ ■ ■ Ql^lfeQ2^2fe ■ • ■ Qnbnk 4 >^ 

which has, of course, an entirely different meaning. 

That the argument used in [BC96] is false does not mean that the size of 
the automaton for a Presburger formula will grow nonelementarily with respect 
to the number of quantifier alternations. Indeed, an analysis of the traditional 
quantifier elimination procedure for Presburger arithmetic [End72] shows the op- 
posite. Looking at this procedure, one notices that the number of basic formulas 
that are generated stays elementary in the size of the initial formula. Whatever 
the quantifier prefix of the formula, the quantifier elimination procedure only 
generates a Boolean combination of this elementary number of formulas. Hence, 
the formula obtained by the quantifier elimination procedure is elementary and 
so will be the corresponding automaton. 

3.4 Pragmatics 

So far, we have tried to present in a fairly detailed way the algorithms used to 
build automata from Presburger formulas. However, there are still a a substantial 
number of “improvements” that can be added to what we have described in 
order to obtain a good implemented system. We discuss here one such important 
improvement. The reader is certainly aware of the fact that one of the drawbacks 
of the automata we are constructing is that their alphabet is exponential in the 
number of variables of the arithmetic formula. Thus, even very simple formulas 
involving many variables will lead to automata with a huge number of transitions. 
Fortunately, there is a way around this. 

The idea is to sequentialize the reading of the bits of the vector components. 
That is, rather than reading a bit vector b = (6i, 62, • ■ ■ , as a single entity, 
one reads 61 , 62, ■ ■ ■ , bn one at a time in a fixed order. The size of the alphabet 
is now always 2 , whatever the number of components of the integer vectors de- 
fined. Of course, the counterpart is that the number of states of the automaton 
is increased, but this increase can be more moderate than the explosion in the 
number of transitions that comes from a large number of variables. This can 
easily be understood by observing that using 2 " as alphabet amounts to repre- 
senting the transitions from a state as a truth table, whereas sequentializing the 
reading of the bits corresponds to representing the transitions from a state as a 
decision diagram for a given bit order. Minimizing the automaton has the effect 
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of minimizing this diagram and one is in fact representing the transitions from 
a state with a structure that is similar to an OBDD [Bry92]. This technique is 
used in the LASH package [LASH] as well as in the MONA tool [HJJ+95]. The 
construction algorithms presented in this paper can easily be adapted to the 
sequentialized encoding of vectors. 



4 Experimental Results 

As discussed above, each application of a projection and determinization con- 
struction to an automaton representing arithmetic constraints is not going to 
yield an exponential blowup in the size of the automaton. The question then is, 
what blowup does in fact occur? To attempt to answer this question, we turned 
to experiments performed with the help of the LASH tool. 

The first experiment consists of applying an existential quantifier to the sets 
of solutions of random systems of linear inequalities. The results obtained for 
100 systems of 8 inequations of dimension 4 with coefficients in the interval 
[—5, . . . , 5] are given in Figure 7. This figure depicts the number of states of the 
quantified automata, which are made deterministic and minimal, with respect 
to the size of the unquantified automata. Note that all the points fall below the 
dotted equality line, which means that the number of states always decreases. 




Fig. 7. Effect of quantification over systems of linear inequalities. 



A second test consists of repeatedly applying an existential quantification 
to the automata of the previous experiment, until only a single free variable 
remains. Figure 8 gives the number of states of the automata obtained during, 
and as a result of, this process, relative to the size of the automaton obtained 
prior to the application of the last quantification operation. 
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Fig. 8. Effect of repeated quantification over systems of linear inequalities. 



Finally, Figure 9 illustrates the effect of applying existential quantification to 
non-convex sets obtained by joining together the sets of solutions of two random 
systems of linear inequalities. 



1(V>« 




10 100 1000 10000 100000 



Fig. 9. Effect of quantification over non-convex sets. 



It is rather surprising that these experiments show that every projection- 
determinization step in fact decreases the size of the automaton, whereas an 
exponential blowup could have been feared. This raises interesting questions, 
for instance, what exact bound can be proved on the size increase resulting 
from projecting and determinizing an arithmetic automaton? What structural 
properties of such automata explain this bound? These are still open questions. 
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5 Conclusions 

There are two sets of conclusions that can be drawn from this paper. The first 
concerns the use of finite automata as a tool for handling Presburger arith- 
metic. The initial construction of an automaton from a quantifier-free formula 
can be exponentially expensive, either as the result of the interaction of many 
constraints or as a consequence of the presence of large multiplicative constants 
in formulas. It is easy to construct examples where this explosion occurs, but 
also to construct examples where things are much tamer. There is however, an 
important benefit linked to this potentially high cost: the automaton is a struc- 
ture in which much of the information contained in the formula is explicit. For 
instance, satisfiability becomes decidable in linear time and inclusion between 
represented sets is, at worst, quadratic. Furthermore, as shown by our experi- 
ments, subsequent manipulation of the automaton need not be very costly. This 
indicates, that if one needs to repeatedly work with and transform a Presburger 
formula, as is often the case in verification applications, adopting the automata- 
based approach might very well be an excellent choice. On the other hand, if one 
is interested in a one shot satisfiability check, traditional approaches have the 
edge since building the automaton involves doing substantially more than just 
checking for the possibility of satisfying the given formula. Of course, only the 
accumulation of experiments coupled with the fine-tuning of tools will give the 
final word on the value of the approach. 

The second set of conclusions is about computing with automata and the 
corresponding complexity bounds. Our special determinization procedure for 
inequation automata as well as our discussion of projection-determinization op- 
erations indicate that the general complexity bounds for automata operations 
do not tell the full story when dealing with automata corresponding to linear 
constraints. For inequation automata, we were able to identify the structure that 
explained the absence of blowup while determinizing. For the determinization of 
the result of a projection operation, our only arguments for the absence of blowup 
comes from a logic-based analysis of the represented sets. It would, however, be 
much more satisfactory to explain the absence of blowup in purely automata- 
theoretic terms, which could lead to more direct and efficient algorithms, just as 
in the case of inequation automata. But, this remains an open problem. 
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Abstract. We present the design and implementation of the type system for 
Ptolemy II, which is a tool for component-based heterogeneous modeling and 
design. This type system combines static typing with run-time type checking. It 
supports polymorphic typing of components, and allows automatic lossless type 
conversion at run-time. To achieve this, we use a lattice to model the lossless 
type conversion relation among types, and use inequalities defined over the type 
lattice to specify type constraints in components and across components. The 
system of inequalities can be solved efficiently, with existence and uniqueness 
of a solution guaranteed by fixed-point theorems. This type system increases the 
safety and flexibility of the design environment, promotes component reuse, 
and helps simplify component development and optimization. The infrastructure 
we have built is generic in that it is not bound to one particular type lattice. The 
type system can be extended in two ways: by adding more types to the lattice, 
or by using different lattices to model different system properties. Higher-order 
function types and extended types can be accommodated in this way. 



1 Introduction 

Ptolemy II [5] is a system-level design environment that supports component-based 
heterogeneous modeling and design. The focus is on embedded systems. In compo- 
nent-based design, each component has an interface, which includes the data type of 
the messages sent or received by the component, and the communication protocols 
used by the component to exchange information with others. In Ptolemy II, the inter- 
connection of components is represented by hierarchical clustered graphs. Intercon- 
nections imply type constraints. In addition, components themselves may have 
constraints on their interface and internal state variables. 

A good type system is particularly important for embedded systems. A type 
system can increase safety though type checking, promote component reuse through 
polymorphic typing, provide services such as automatic type conversion, and help 
optimize the design by finding low cost typing for polymorphic components. 

Ptolemy II supports heterogeneous design by providing a variety of models of 
computation (MoCs) [5]. It can be viewed as a coordination language where it man- 
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ages the communication among independent components without much knowledge 
about the computation they carry out. In this regard, it is similar to other coordination 
languages like Manifold [2]. In different MoCs, component interaction obeys 
different semantics. However, this level of detail can be ignored in data level type 
system design, and a general message passing semantics can be assumed. This 
abstraction enables the same type system to work with widely differing models. Fig. 1 
shows a simplified graph representation of a Ptolemy II model. In Ptolemy II 
terminology, each of the components A, B, and C is an actor, and actors contain 
ports, denoted by the small circles on the actors. Actors send and receive messages 
through ports. Messages are encapsulated in tokens, which are typed. 

In general-purpose languages, there are two approaches for type system design: 
static typing and dynamic typing. Research in this area is driven to a large degree by 
the desire to combine the flexibility of dynamically typed languages with the security 
and early error-detection potential of statically typed languages. Polymorphic type 
systems of modern languages have achieved this goal to a large extent [14]. Since 
Ptolemy II is intended for large, complex, and possibly safety-critical system design, 
we choose static typing for its obvious advantages. To do this, we give each actor port 
a type. This type restricts the type of tokens that can pass though the port. Based on 
the port types and the graph topology, we can check the type consistency in the model 
statically, before it is executed. In Ptolemy II, static checking alone is not enough to 
ensure type safety at run-time because Ptolemy II is a coordination language, its type 
system does not have detailed information about the operation of each actor, except 
the declared types of the ports and the type constraints provided by the actors. In fact, 
Ptolemy II places no restriction on the implementation of an actor. So an actor may 
wrap a component implemented in a different language, or a model built by a foreign 
tool [11]. Therefore, even if a source actor declares its port type to be Int, no static 
structure prevents it from sending a token containing Double at run-time. The 
declared type Int in this case is only a promise from the actor, not a guarantee. 
Analogous to the run-time type checking in Java, the components are not trusted. 
Static type checking checks whether the components can work together as connected 
based on the information given by each component, but run-time type checking is also 
necessary for safety. With the help of static typing, run-time type checking can be 
done when a token is sent from a port. I.e., the run-time type checker checks the token 
type against the type of the port. This way, a type error is detected at the earliest 
possible time, and run-time type checking (as well as static type checking) can be 
performed by the system infrastructure instead of by the actors. 

Another benefit of static typing is that it allows the system to perform lossless 
type conversion. For example, if a sending port with type Int is connected to a 
receiving port with type Double, the integer token sent from the sender can be 




22 Yuhong Xiong and Edward A. Lee 



converted to a double token before it is passed to the receiver. This kind of run-time 
type conversion is done transparently by the Ptolemy II system (actors are not aware 
it). So the actors can safely cast the received tokens to the type of the receiving port. 
This makes actor development easier. As a design principle of Ptolemy II, the system 
does not implicitly perform data type conversions that lose information. The lossless 
type conversion relation among different types is modeled as a partially ordered set, 
called the type lattice. 

In Ptolemy II, polymorphic actors are actors that can accept multiple types on 
their ports. In general, the types on some or all of the ports of a polymorphic actor are 
not rigidly defined to specific types when the actor is written, so the actor can interact 




Fig. 1. A simplified Ptolemy II model. 

with other actors having different types. The acceptable types on polymorphic actors 
are described by a set of type constraints, which have the form of inequalities defined 
over the type lattice. The static type checker checks the applicability of a polymorphic 
actor in a topology (an interconnection of components) by finding specific types for 
them that satisfy the type constraints. This process, called type resolution, can be done 
by a very efficient algorithm. 

In addition to maintaining type consistency for data transfer, our type system plays 
a larger role. In a component-based architecture, there are two ways to get data to 
components: static configuration (via parameters) and dynamic message passing (via 
ports). Our system allows constraints on the types of parameters, as well as the types 
of ports. In addition, Ptolemy II permits state variables that are local to a component 
to he typed, so type constraints between ports, parameters, and state variables can all 
be expressed. 

Besides the models based on message passing, Ptolemy II also supports control 
oriented models, such as finite state machines (FSM), which represent a system as a 
sequence of state transitions in response to events. In this model, type constraints can 
link the transition guard and the event of the state machine. Hierarchical FSMs can be 
mixed with other concurrency models [7]. In these mixed models, type constraints can 
be propagated between the events of the control model and the data of the other con- 
currency models. Section 4.2 below shows an example of this. 







An Extensible Type System for Component-Based Design 23 



Our type system is related to the work of Fuh and Mishra [6] that extended poly- 
morphic type inference in ML [12] with subtypes. The lossless type conversion rela- 
tion is a subtype relation. However, there are several key differences between our 
approach and the ML type system and the system of Fuh and Mishra. First, the ML 
type inference algorithm produces principal types. Principal types are the most 
general types for a program in that any other legal type assignment is a substitution 
instance of it. In our system, the type resolution algorithm finds the most specific type 
rather than the most general type. This specific type is the least fixed point solution 
for the type constraints rather than the greatest fixed point. As we will see, using the 
most specific type may help optimize the system under design, as the most specific 
type usually has a lower implementation cost. Second, the ML type system does all 
the checking statically, while our system combines static and run-time checking. As 
discussed above, we assume that the system components are opaque to the type 
system. The type system does not have detailed knowledge of the operation of the 
components, so static checking alone cannot guarantee run-time safety. Our combined 
approach can detect errors at the earliest possible time and minimize the computation 
of run-time checking. Third, the system of Fuh and Mishra allows arbitrary type 
conversion, represented by a coercion set, while our system concentrates on lossless 
conversion. This focus permits the conversion relation to form a lattice structure, and 
the type constraints to be expressed as inequalities on the lattice. As a result, the type 
constraints can be solved by a linear time algorithm, which is more efficient than the 
algorithm to check the consistency of a coercion set. 

The advantage of a constraint-based approach, like ours, is that constraint resolu- 
tion can be separated from constraint generation, and resolution can employ a 
sophisticated algorithm. Although the users need to understand the constraint 
formulation, they do not have to understand the details of the resolution algorithm in 
order to use the system. In addition, the constraint resolution algorithm can be built as 
a generic tool that can be used for other applications. Even more important in Ptolemy 
II, the types are not aware of the constraints, so more types can be added to the type 
lattice, resulting in an extensible type system. 

2 Ptolemy II 

Ptolemy II offers a unified infrastructure for implementation of a number of models of 
computation. It consists of a set of Java packages. The key packages relevant to the 
type system are the kernel, actor, data, and graph packages. 

2.1 The Kernel Package 

The kernel package defines a small set of Java classes that implement a data structure 
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supporting a general form of uninterpreted clustered graphs, plus methods for access- 
ing and manipulating such graphs. These graphs provide an abstract syntax for 
netlists, state transition diagrams, block diagrams, etc. A graph consists of entities and 
relations. Entities have ports. Relations connect entities through ports. Relations are 
multi-way associations. Hierarchical graphs can be constructed by encapsulating one 
graph inside the composite entity of another graph. This encapsulation can be nested 
arbitrarily. 

2.2 The Actor Package 

The actor package provides basic support for executable entities, or actors. It supports 
a general form of message passing between actors. Messages are passed between 
ports, which can be inputs, outputs or bidirectional ports. Actors can be typed, which 
means that their ports have a type. The type of the ports can be declared by the 
containing actor, or left undeclared on polymorphic actors; type resolution will 
resolve the types according to type constraints. Messages are encapsulated in tokens 
that are implemented in the data package or in user-defined classes extending those in 
the data package. 

A subpackage of the actor package contains a library of (currently) about 40 poly- 
morphic actors. 

2.3 The Data Package 

The data package provides data encapsulation, polymorphism, parameter handling, 
and an expression language. Data encapsulation is implemented by a set of token 
classes. For example, IntToken contains an integer, DoubleMatrixToken contains a 
two-dimensional array of doubles. The tokens can be transported via message passing 
between Ptolemy II objects. Alternatively, they can be used to parameterize Ptolemy 
II objects. Such encapsulation allows for a great degree of extensibility, permitting 
developers to extend the library of data types that Ptolemy II can handle. 

One of the goals of the data package is to support polymorphic operations between 
tokens. For this, the base Token class defines methods for the primitive arithmetic 
operations, such as add(), multiplyO, subtract)), divide)), modulo)) and equals)). 
Derived classes override these methods to provide class specific operations where 
appropriate. 

Parameter handling and an extensible expression language, including its inter- 
preter, are supported by a subpackage inside the data package. A parameter contains a 
token as its value. This token can be set directly, or specified by an expression. An 
expression may refer to other parameters, and dependencies and type relationships 
between parameters are handled transparently. 
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2.4 The Graph Package 

This package provides algorithms for manipulating and analyzing mathematical 
graphs. Mathematical graphs are simpler than Ptolemy II clustered graphs in that there 
is no hierarchy, and arcs link exactly two nodes. Both undirected and directed graphs 
are supported. Acyclic directed graphs, which can be used to model complete partial 
orders (CPOs) and lattices [4], are also supported with more specialized algorithms. 
This package provides the infrastructure to construct the type lattice and implement 
the type resolution algorithm. However, this package is not aware of the types; it sup- 
plies generic tools that can used in different applications. 

3 Type System Formulation 

3.1 The Type Lattice 

A lattice is a partially ordered set in which every subset of elements has a least upper 
bound and a greatest lower bound [4]. This mathematical structure is used to represent 
the lossless type conversion relation in a type system. An example of a type lattice is 
shown in Fig. 2. This particular lattice is constructed in the data package using the 
infrastructure of the graph package. In the diagram, type a is greater than type (3 if 
there is a path upwards from (3 to a. Thus, ComplexMatrix is greater than Int. Type a 
is less than type (3 if there is a path downwards from (3 to a. Thus, Int is less than 
ComplexMatrix. Otherwise, types a and (3 are incomparable. Complex and Long, for 
example, are incomparable. The top element. General, which is “the most general 
type,” corresponds to the base token class; the bottom element, NaT (Not a Type), 
does not correspond to a token. Users can extend a type lattice by adding more types. 

In the type lattice, a type can be losslessly converted to any type greater than it. 
For example, an integer can be losslessly converted to a double. Here, we assume an 
integer is 32 bits long and a double is 64 bits using the IEEE 754 floating point 
format, as in Java. This hierarchy is related to the inheritance hierarchy of the token 
classes in that a subclass is always less than its super class in the type lattice, but 
some adjacent types in the lattice are not related by inheritance. So this hierarchy is a 
combination of the subtyping relation in object oriented languages, and ad hoc 
subtyping rules, such as Int < Double [13]. Organizing types in a hierarchy is fairly 
standard. For example, Abelson and Sussman [1] organized the coercion relation 
among types in a hierarchy. However, they did not deliberately model the hierarchy as 
a lattice. Long ago, Hext [9] experimented with using a lattice to model the type 
conversion relation, but he was not working with an object oriented language and did 
not intend to support polymorphic system components. This work predates the 
popular use of those concepts. 
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General 




Fig. 2. An example of a type lattice. 

Type conversion is done by a method convert() in the token classes. This method 
converts the argument into an instance of the class implementing this method. For 
example, DoubleToken.convert(Token token) converts the specified token into an 
instance of DoubleToken. The convert)) method can convert any token immediately 
below it in the type hierarchy into an instance of its own class. If the argument is sev- 
eral levels down the type hierarchy, the convert)) method recursively calls the con- 
vert)) method one level below to do the conversion. If the argument is higher in the 
type hierarchy, or is incomparable with its own class, convert)) throws an exception. 
If the argument to convert)) is already an instance of its own class, it is returned 
without any change. 

3.2 Type Constraints 

In Ptolemy II, to guarantee that information is not lost during data transfer, we require 
the type of a port that sends tokens to be the same as or lower than the type of the 
receiving port: 



sendType < receiveType 



) 1 ) 
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If both the sendType and receiveType are declared, the static type checker simply 
checks whether this inequality is satisfied, and reports a type conflict if it is not. 

In addition to the above constraint imposed by the topology, actors may also 
impose constraints among ports and parameters. For example, the Ramp actor in 
Ptolemy II, which is a source actor that produces a token on each execution with a 
value that is incremented by a specified step, stores the first output and the step value 
in two parameters. This actor will not declare the type of its port, but will specify the 
constraint that the port type is greater than or equal to the types of the two parameters. 
As another example, a polymorphic Distributor actor, which splits a single token 
stream into a set of streams, will specify the constraint that the type of a sending port 
is greater than or equal to that of the receiving port. This Distributor will be able to 
work on tokens of any type. In general, polymorphic actors need to describe the 
acceptable types through type constraints. 

All the type constraints in Ptolemy II are described in the form of inequalities like 
the one in (1). If a port or a parameter has a declared type, its type appears as a con- 
stant in the inequalities. On the other hand, if a port or a parameter has an undeclared 
type, its type is represented by a type variable in the inequalities. The domain of the 
type variable is the elements of the type lattice. The type resolution algorithm resolves 
the undeclared types in the constraint set. If resolution is not possible, a type conflict 
error will be reported. As an example of a constraint set, consider Fig. 3. 

The port on actor A1 has declared type Int\ the ports on A3 and A4 have declared 
type Double', and the ports on A2 have their types undeclared. Let the type variables 
for the undeclared types be a, (3, and y; the type constraints from the topology are: 

Int < a 
Double < (3 
Y < Double 

Now, assume A2 is a polymorphic adder, capable of doing addition for integer, 
double, and complex numbers. Then the type constraints for the adder can be written 
as: 

Int < a 
Double < P 
Y < Double 




Fig. 3. A topology (interconnection of components) with types. 
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a< Y 

P<Y 

Y < Complex 

The first two inequalities constrain the precision of the addition result to be no less 
than that of the summands, the last one requires that the data on the adder ports can be 
converted to Complex losslessly. These six inequalities form the complete set of con- 
straints and are used by the type resolution algorithm to solve for a, (3, and y. 

This inequality formulation is inspired by the type inference algorithm in ML [12]. 
There, type equations are used to represent type constraints. In Ptolemy II, the lossless 
type conversion hierarchy naturally implies inequality relations among the types 
instead of equalities. In ML, the type constraints are generated from program con- 
structs. In a heterogeneous graphical programming environment like Ptolemy II, 
where details of the components are hidden, the system does not have enough 
information about the function of the actors, so the actors must present their type 
information by either declaring the type on their port, or by specifying a set of type 
constraints to describe the acceptable types on the undeclared ports. The Ptolemy II 
system also generates type constraints based on (1). 

This formulation converts type resolution into a problem of solving a set of ine- 
qualities defined over a finite lattice. An efficient algorithm for doing this is given by 
Rehof and Mogensen [15]. The appendix of this paper describes this algorithm 
through an example. Essentially, the algorithm starts by assigning all the type 
variables the bottom element of the type hierarchy, NaT, then repeatedly updating the 
variables to a greater element until all the constraints are satisfied, or until the 
algorithm finds that the set of constraints are not satisfiable. This process can be 
formulated as the search for the least fixed point of a monotonic function on the 
lattice. The least fixed point is the set of most specific types. It is unique [4], and 
satisfies the constraints if it is possible to satisfy the constraints. 

If the set of type constraints are not satisfiable, or some type variables are resolved 
to NaT, the static type checker flags a type conflict error. The former case can happen, 
for example, if the port on actor A1 in figure Fig. 3 has declared type Complex. The 
latter can happen if an actor does not specify any type constraints on an undeclared 
sending port. If the type constraints do not restrict a type variable to be greater than 
NaT, it will stay at NaT after resolution. To avoid this, any sending port must either 
have a declared type, or some constraints to force its type to be greater than NaT. 

A solution satisfying the constraints may not be unique. In fact, the algorithm 
given in [15] can be used to find either the most specific solution (least in the lattice) 
or the most general solution (greatest in the lattice). The ML type inference algorithm 
finds the most general types for a given program, which allows maximal reuse of 
compiled code. In our case, multiple occurrences of an actor in a topology are treated 
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as different actors, even though they specify the same set of type constraints, so we do 
not need to use the most general type. In fact, our choice of using the most specific 
types has a key advantage: types lower in the type lattice usually have a lower 

implementation cost. For example, in embedded system design, hardware is often 
synthesized from a component-based description of a system. If a polymorphic adder 
is going be synthesized into hardware, and it receives Int tokens and sends the 
addition result to a Double port, our scheme will resolve the types of all the ports on 
the adder to Int, rather than Double. Using an integer adder will be more economical 
than a double adder. This is analogous to using types to generate more optimized code 
in compilers. 

3.3 Run-Time Type Checking and Lossless Type Conversion 

The declared type is a contract between an actor and the Ptolemy II system. If an actor 
declares that a sending port has a certain type, it asserts that it will only send tokens 
whose types are less than or equal to that type. If an actor declares a receiving port to 
have a certain type, it requires the system to only send tokens that are instances of the 
class of that type to that port. Run-time type checking is the component in the system 
that enforces this contract. When a token is sent from a sending port, the run-time 
type checker finds its type, and compares it with the declared type of the port. If the 
type of the token is not less than or equal to the declared type, a run-time type error 
will be reported. 

As discussed before, type conversion is needed when a token sent to a receiving 
port has a type less than the type of that port but is not an instance of the class of that 
type. Since this kind of lossless conversion is done automatically, an actor can safely 
cast a received token to the declared type. On the other hand, when an actor sends 
tokens, the tokens being sent do not have to have the exact declared type of the 
sending port. Any type that is less than the declared type is acceptable. For example, 
if a sending port has declared type Double, the actor can send IntToken from that port 
without having to convert it to a DoubleToken, since the conversion will be done by 
the system. So the automatic type conversion simplifies the input/output handling of 
the actors. 

Note that even with the convenience provided by the type conversion, actors 
should still declare the receiving types to be the most general that they can handle and 
the sending types to be the most specific that includes all tokens they will send. This 
maximizes their applications. In the previous example, if the actor only sends 
IntToken, it should declare the sending type to be Int to allow the port to be connected 
to a receiving port with type Int. 

If an actor has ports with undeclared types, its type constraints can be viewed as 
both a requirement and an assertion from the actor. The actor requires the resolved 
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types to satisfy the constraints. Once the resolved types are found, they serve the role 
of declared types at run time. I.e., the type checking and type conversion system guar- 
antees to only put tokens that are instances of the class of the resolved type to receiv- 
ing ports, and the actor asserts to only send tokens whose types are less than or equal 
to the resolved type from sending ports. 

3.4 Discussion of Type Resolution and Polymorphism 

Rehof and Mogensen proved that their algorithm for solving inequality constraints is 
linear time in the number of occurrences of symbols in the constraints, which in our 
case, can be translated into linear time in the number of constraints. This makes type 
resolution very efficient. On the other hand, one might be tempted to extend the 
formulation to achieve more flexibility in type specification. For example, it would be 
nice to introduce a OR relation among the constraints. This can be useful, in the case 
of a two-input adder, for specifying the constraint that the types of the two receiving 
ports are comparable. This constraint will prohibit tokens with incomparable types to 
be added. As shown in [15], this cannot be easily done. The inequality constraint 
problem belongs to the class of meet-closed problems. Meet-closed, in our case, 
means that if A and B are two solutions to the constraints, their greatest lower bound 
in the lattice is also a solution. This condition guarantees the existence of the least 
solution, if any solution exists at all. Introducing the OR relation would break the 
meet-closed property of the problem. Rehof and Mogensen also showed that any strict 
extension of the class of meet-closed problems solved by their algorithm will lead to 
an NP-complete problem. So far, the inequality formulation is generally sufficient for 
our purpose, but we are still exploring its limitations and workarounds. 

We have been using the term polymorphic actor broadly to mean the actors that 
can work with multiple types on their ports. In [3], Cardelli and Wegner distinguished 
two broad kinds of polymorphism: universal and ad hoc polymorphism. Universal 
polymorphism is further divided into parametric and inclusion polymorphism. 
Parametric polymorphism is obtained when a function works uniformly on a range of 
types. Inclusion polymorphism appears in object oriented languages when a subclass 
can be used in place of a superclass. Ad hoc polymorphism is also further divided into 
overloading and coercion. In terms of implementation, a universally polymorphic 
function will usually execute the same code for different types, whereas an ad-hoc 
polymorphic functions will execute different code. 

In an informal sense, Ptolemy II exhibits all of the above kinds of polymorphism. 
The Distributor actor, discussed in section 3.2 shows parametric polymorphism 
because it works with all types of tokens uniformly. If an actor declares its receiving 
type to be General, which is the type of the base token class, then that actor can 
accept any type of token since all the other token classes are derived from the base 
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token class. This is inclusion polymorphism. The automatic type conversion during 
data transfer is a form of coercion; it allows an receiving port with type Complex, for 
example, to be connected to sending ports with type Int, Double or Complex. An 
interesting case is the arithmetic and logic operators, like the Add actor. In most 
languages, arithmetic operators are overloaded, but different languages handle 
overloading differently. In standard ML, overloading of arithmetic operators must be 
resolved at the point of appearance, but type variables ranging over equality types are 
allowed for the equality operator [16]. In Haskell, type classes are used to provide 
overloaded operations [8]. Ptolemy II takes advantage of data encapsulation. The 
token classes in Ptolemy II are not passive data containers, they are active data in the 
sense that they know how to do arithmetic operations with another token. This way, 
the Add actor can simply call the add() method of the tokens, and work consistently 
on tokens of different type. An advantage of this design is that users can develop new 
token types with their implementation for the add() method, achieving an effect 
similar to user defined operator overloading in C-H-. 



4 Examples 

This section provides two examples of type resolution in Ptolemy II. 



4.1 Fork Connection 



Consider two simple topologies in Fig.4. where a single sending port is connected to 
two receiving ports in Fig. 4(a) and two sending ports are connected to a single receiv- 
ing port in Fig.4(b). Denote the types of the ports by al, a2, a3, bl, b2, b3, as 
indicated in the figure. Some possibilities for legal and illegal type assignments are: 



• In Fig.4(a), if al = Int, a2 = Double, a3 = Complex. The topology 
is well typed. At run-time, the IntToken sent out from actor Al 
will be converted to DoubleToken before transferred to A2, and 
converted to ComplexToken before transferred to A3. This shows 
that multiple ports with different types can be interconnected as 
long as the sender type can be losslessly converted to the receiver 
type. 





Fig. 4. Two simple topologies with types. 
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• In Fig. 4(b), if bl = Int, b2 = Double, and b3 is undeclared. The the resolved type 
for b3 will be Double. If bl = Int and b2 = Boolean, the resolved type for b3 will 
be String since it is the lowest element in the type hierarchy that is higher than 
both Int and Boolean. In this case, if the actor B3 has some type constraints that 
require b3 to be less than String, then type resolution is not possible, a type con- 
flict will be signaled. 

A Java applet that demonstrates the situation in Fig.4(b) and shows the type 
resolution process is available at the URL: http://ptolemy.eecs.berkeley.edu/ 
ptolemylU ptIIO. 3/ptIIO. 3/ptolemy/domains/sdf/demo/Type/T ype. htm 

4.2 Mixing FSM and SDF 

In [7], Girault, Lee and Lee showed how to mix finite-state machines (FSMs) with 
other concurrency models. For example FSM can be mixed with synchronous 
dataflow (SDF) [10], as shown in Fig. 5. In this figure, the top of the hierarchy is an 
SDF system. The middle actor B in this system is refined to a FSM with two states, 
each of which is further refined to a SDF subsystem. One type constraint on the 
receiving port of B is that its type must be less than or equal to the types of both of the 
receiving ports of the SDF subsystems D and E, because tokens may be transported 
from the receiving port of B to the receiving ports of D or E. Assuming the types of 
the receiving ports on D and E are Int and Double, respectively, type resolution will 
resolve the type of the receiving port of B to Int. Similarly, a type constraint for the 
sending port of B is that its type must be greater than or equal to the types of both of 
the sending ports of D and E, and its resolved type will be Double. 

Note that this result is consistent with function subtyping [13]. If we consider the 
order in the type lattice as subtype relations, and the actors as functions, then D: 
Int-^Int, E: Double -^Double , and B: a— >(3 before type resolution. Since D and E can 
take the place of B during execution, their types should be considered as subtypes of 
the type of B. Since function subtyping is contravariant for function arguments and 
covariant for function results, the type a should be a subtype of Int and Double and (3 
should be a super type of Int and Double. This is exactly what the type constraints 
specify, and the resulting type for B: Int-^Double is indeed a supertype of both of the 
types of D and E. 
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Fig. 5. Mixing FSM with SDF. 



5 Conclusion and Future Work 

In the design of the Ptolemy II type system, we have taken the approach of polymor- 
phic static typing combined with run-time type checking. We use a lattice structure to 
model the lossless type conversion relation and provide automatic type conversion 
during data transfer. Polymorphism is supported by allowing the system components 
to specify type constraints, and a linear time algorithm is used for constraint resolu- 
tion. This type system increases the safety and usability of the component-based 
design environment, promotes component reuse, and helps with design optimization. 
The infrastructure is built to operate on any type lattice, and so can be used to experi- 
ment with extended type systems. 

Currently, we are working on extending this system to support structured types 
such as array and record types. The goal is to allow the elements of arrays and records 
to contain tokens of arbitrary types, including structured types, and to be able to spec- 
ify type constraints on them. One of the major difficulty with this extension is that the 
type lattice will become infinite, which raises questions on the convergence of type 
resolution. 

In the longer term, we will try to characterize the communication protocols used 
between system components, or some of the real-time properties of the system as 
types, and design a process-level type system to facilitate heterogeneous real-time 
modeling. This may potentially bring some of the benefit of data typing to the process 
level. 
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Appendix The Type Resolution Algorithm 

The type resolution algorithm starts by assigning all the type variables the bottom ele- 
ment of the type hierarchy, NaT, then repeatedly updating the variables to a greater 
element until all the constraints are satisfied, or until the algorithm finds that the set of 
constraints are not satisfiable. This iteration can be viewed as repeated evaluation of a 
monotonic function, and the solution is the least fixed point of the function. The kind 
of inequality constraints for which the algorithm can determine satisfiability are the 
ones with the greater term being a variable or a constant. By convention, we write ine- 
qualities with the lesser term on the left and the greater term on the right, as in a < (3, 
not (3 > a. The algorithm allows the left side of the inequality to contain monotonic 
functions of the type variables, but not the right side. The first step of the algorithm is 
to divide the inequalities into two categories, Cvar and Ccnst. The inequalities in 
Cvar have a variable on the right side, and the inequalities in Ccnst have a constant on 
the right side. In the example of Fig. 3, Cvar consists of: 

Int < a 
Double < (3 
a< Y 
(3<y 

And Ccnst consists of: 

Y < Double 
Y< Complex 

The repeated evaluations are only done on Cvar, Ccnst are used as checks after the 
iteration is finished, as we will see later. Before the iteration, all the variables are 
assigned the value NaT, and Cvar looks like: 

Int < oXNaT) 

Double < (3(AaT) 
oXNaT) < j(NaT) 

^(NaT) < jiNaT) 

Where the current value of the variables are inside the parenthesis next to the variable. 

At this point, Cvar is further divided into two sets: those inequalities that are not 
currently satisfied, and those that are satisfied: 
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Not- satisfied Satisfied 

Int < oXNaT) a(NaT) < j(NaT) 

Double < ^(NaT) ^(NaT) < y(NaT) 

Now comes the update step. The algorithm selects an arbitrary inequality from the 
Not-satisfied set, and forces it to be satisfied by assigning the variable on the right 
side the least upper bound of the values of both sides of the inequality. Assuming the 
algorithm selects Int < a(NaT), then 

(2)a = IntvNaT = Int 

After a is updated, all the inequalities in Cvar containing it are inspected and are 
switched to either the Satisfied or Not-satisfied set, if they are not already in the 
appropriate set. In this example, after this step, Cvar is: 

Not-satisfied Satisfied 

Double < P(Aa7) Int < aXInt) 

a(Int) < j{NaT) ^(NaT) < y(NaT) 

The update step is repeated until all the inequalities in Cvar are satisfied. In this 
example, p and y will be updated and the solution is: 
a = Int, P = y = Double 

Note that there always exists a solution for Cvar. An obvious one is to assign all 
the variables to the top element. General, although this solution may not satisfy the 
constraints in Const. The above iteration will find the least solution, or the set of most 
specific types. 

After the iteration, the inequalities in Const are checked based on the current value 
of the variables. If all of them are satisfied, a solution to the set of constraints is 
found. 

As mentioned earlier, the iteration step can be seen as a search for the least fixed 
point of a monotonic function. In this view, the computation in (2) is the application 
of a monotonic function to type variables. Let L denote the type lattice. In an 
inequality r < a, where a is a variable, and r is either a variable or a constant, the 
update function/: —> L is a’ = fir, a) = r v a. Here, a represents the value of the 

variable before the update, and a’ represents the value after the update. /can easily be 
seen to be monotonic and non-decreasing. And, since L is finite, it satisfies the 
ascending chain condition, so /is also continuous. Let the variables in the constraint 
set be CLi, 0,2, ... , OCaj, where A is the total number of variables, and define A = (tty, 0,2, 
... , CLfi). The complete iteration can be viewed as repeated evaluation of a function F\ 
ifi ifi of A, where F is the composition of the individual update functions. Clearly, 
F is also continuous. The iteration starts with the variables initialized to the bottom, A 
= _L^, and computes the sequence F'(-L^) (i > 0), which is a non-decreasing chain. By 
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the fixed point theorem in [4], the least upper hound of this chain is the least fixed 
point of F, corresponding to the most specific types in our case. 

Rehof and Mogensen [15] proved that the above algorithm is linear time in the 
number of occurrences of symbols in the constraints, and gave an upper bound on the 
number of basic computations. In our formulation, the symbols are type constants and 
type variables, and each constraint contains two symbols. So the type resolution algo- 
rithm is linear in the number of constraints. 
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Abstract. This note describes Proof General, a tool for developing ma- 
chine proofs with an interactive proof assistant. Interaction is based 
aronnd a proof script, which is the target of a proof development. Proof 
General provides a powerful user-interface with relatively little effort, 
alleviating the need for a proof assistant to provide its own GUI, and 
providing a uniform appearance for diverse proof assistants. 

Proof General has a growing user base and is currently used for several 
interactive proof systems, including Coq, LEGO, and Isabelle. Support 
for others is on the way. Here we give a brief overview of what Proof 
General does and the philosophy behind it; technical details are available 
elsewhere. The program and user documentation are available on the web 
at http : //www.dcs . ed. ac.uk/home/proofgen. 

1 Background 

Proof General is a generic interface for interactive proof assistants. 

A proof assistant is a computerized helper for developing machine proofs. 
There are many uses for machine proofs, both during the specification, develop- 
ment, and verification of software and hardware systems, and in the development 
and teaching of mathematical proof and formal logic. Proof General helps with 
developing proof scripts. 

A proof script is a sequence of commands sent to a proof assistant to con- 
struct a machine proof. A script is usually stored in a file. Roughly, a proof 
script is like a program written in a scripting programming language, and in 
particular, a language which has an interactive interpreter. Proof General uses a 
technique called script management to help the user write a proof script without 
using cut-and-paste or repeatedly typing “load file” commands. Proof General 
has a sophisticated implementation of script management which covers large 
developments spread across multiple files. 

A guiding philosophy behind Proof General is to provide an interface which 
is useful to novices and expert-users alike. Some interfaces for theorem provers 
are aimed at novices and become infeasible for large developments; others are 
aimed at experts but have steep learning curves or require changes in work 
methods, discouraging their take-up. With this in mind. Proof General builds 
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on the programmable text editor Emacs, the powerful everyday editor of many 
computer scientists. Emacs brings many advantages. It is available on most plat- 
forms, including Unix, Linux, and NT. Although it once had a reputation for 
being hard to learn, modern versions of Emacs are very user-friendly, supporting 
the whole gamut of current GUI technologies and providing easy customization 
mechanisms. 

Another important aspect of Proof General is that it is generic. It provides a 
uniform interface and interaction mechanism for different back-end proof assis- 
tants. It exploits the deep similarities between systems by hiding some of their 
superficial differences. This generic aspect is no empty claim or untested design 
goal; Proof General is already in use for three different proof assistants: Goq, 
LEGO, and Isabelle. Support for more is on the way. 

The present implementation of Proof General is oriented towards proof as- 
sistants based on a single-threaded interactive command interpreter (or shell), 
where interaction consists of a dialogue between the user and the system. Several 
proof assistants have this kind of architecture, allowing more elaborate interfaces 
to be built on top. As a spin-off, building Proof General has suggested some use- 
ful design guidelines for the command protocol which should be implemented in 
a proof assistant shell. 

To summarize. Proof General provides a fairly elaborate yet unobtrusive 
interface. It gives the proof assistant user many useful features, and allows the 
proof assistant implementor to concentrate on the proof engine. 



2 Features of Proof General 

Simplified communication. The proof assistant’s shell is hidden from the user. 
Gommunication takes place via two or three buffers (Emacs text widgets). The 
script buffer holds input, the commands to construct a proof. The goals buffer 
displays the current list of subgoals to be solved. The response buffer displays 
other output from the proof assistant. The user sees only the output from the 
latest proof step, rather than a screen full of output. Nonetheless, the user can 
still access the shell to examine it or run commands. 

Script management. Proof script editing is connected to the proof process, main- 
taining consistency between the edit window and the state of the proof assistant. 
Visual feedback on the state of the assistant is given by colouring the background 
of the text in the editing windows. Parts of a proof script that have been pro- 
cessed are displayed in blue and moreover can be locked to prevent accidental 
editing. Parts of the script currently being processed by the proof assistant are 
shown in red. The screenshot in Figure 1 shows script managament in action. 

Multiple file handling. Script management also works across multiple files. When 
a script is loaded in the editor, it is coloured to reflect whether the proof as- 
sistant has processed it in this session. Proof General communicates with the 
assistant to discover dependencies between script files. If I want to edit a file 



40 



David Aspinall 



which has been processed already, Proof General will retract the file and all the 
files which depend on it, unlocking them. Thus the editor is connected to the 
theory dependency or make system of the proof assistant. 

Proof by Pointing. Clicking on a subterm of a goal can apply an appropriate 
rule or tactic automatically, or display a menu of choices. Proof General relies 
on support in the assistant to mark-up subterms and generate tactics for this 
feature, since it is specific to the prover’s syntax and logic. Subterm mark-up 
also makes it easy to explore compilicated terms, and cut and paste from within 
them. 

Syntax highlighting and symbol fonts. Proof scripts are decorated: proof com- 
mands are highlighted and different fonts can be used for definitions and assump- 
tions, for example. Symbol fonts can be used to display proper glyphs for logical 
operators, Greek letters, etc, which occur throughout mathematical proofs. 

Toolbar and menus. A toolbar includes buttons for examining the proof state, 
starting a proof, manoeuvring in the proof script, saving a proof, searching for 
a theorem, interrupting the assistant, and getting help. A menu gives access to 
further commands, and a useful collection of user preferences. Using the toolbar, 
you can replay proofs without knowing any low-level commands of the proof 
assistant or any Emacs short-cuts. 

Tags and definitions menu. Using a TAGS file, one can quickly locate the def- 
inition and uses of an identifier, automatically searching many files. Using a 
definitions menu, one can quickly navigate within a proof script to find particu- 
lar definitions, declarations and proofs. 

Remote proof assistant. A proof assistant can be run remotely, perhaps across 
the internet, while Proof General and the proof script reside locally. 

3 Proof General in Use 

Figure 1 shows a screenshot of Proof General running in a single window on the 
screen. The window is split into two parts. The upper half displays the proof 
script Group . thy which is being processed. This is a script written for Isabelle 
using the new Isar proof language [4]. The lower half displays the current list 
of subgoals which are to be solved to complete the proof. Instead of this split 
window, it is perfectly possible to have separate windows on the screen, as the 
user likes. Proof General is even happy to run on a plain console, although 
graphical facilities will be reduced (e.g. no toolbar). 

In the script file, the cursor appears at the end of the locked region, which has 
a blue background to indicate it has already been processed. The arrow buttons 
on the toolbar are used to manipulate the locked region, by sending commands 
to the proof assistant, or by issuing undo steps. In this manner, a user can replay 
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Fig. 1. Using Proof General 



a proof interactively, without needing to know any low-level commands needed 
to start the proof assistant, or issue proof and undo steps. And without the 
extreme tedium of cut-and-paste. 

4 Further Details 

Technical references. Proof General has a detailed user manual [1] which also 
contains instructions for instantiating it to new proof assistants. The ideas of 
script management and proof by pointing were adapted from the GtGoq sys- 
tem [.3]; proof by pointing in Proof General is described in an LFGS technical 
report [2]. (Proof General goes beyond GtGoq in some ways, but is less sophisti- 
cated in others; the biggest difference is that GtGoq provides its own GUI based 
on structure editing, which Proof General specifically avoids.) Future papers will 
describe the architecture of Proof General in more detail, including design guide- 
lines for interactive proof development protocols, and plans for future directions. 
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Implementation. Proof General is implemented in Emacs Lisp. There is a generic 
core (about 7000 lines) which implements the toolbar, menus, script manage- 
ment, and process handling features. Each supported proof assistant has some 
additional Emacs Lisp (30 - 500 lines) for prover-specific configuration: setting 
regular expressions and command strings, and perhaps providing extra features. 
For robust operation and features like proof by pointing, the proof assistant may 
need modification to output special messages for Proof General. 

Availability and System requirements. Proof General is easy to install, and is 
available free of charge (with sources and documentation) for research and edu- 
cational use. The current release is Proof General 3.0. For best results, it requires 
a recent version of XEmacs (21.1 or later), alongside recent versions of one or 
more proof assistants: Goq (6.3 or later), Isabelle (version 99 or later), or Lego 
(version 1.3.1). Details of where to obtain these components can be found on 
the web page mentioned below. Success is guaranteed with a Unix (or Linux) 
environment, although XEmacs and some proof assistants are available for other 
operating systems, and there is nothing operating system specific in Proof Gen- 
eral itself. 
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Abstract. Co-operative development of distributed software systems involves to 
address the multiple perspectives problem: many stakeholders with diverse do- 
main knowledge and differing development strategies collaborate to construct 
heterogeneous development artifacts using different representation schemes. 
The Viewpoints framework has been developed for organizing multiple 
stakeholders, the development processes and notations they use, and the partial 
specifications they produce. In this contribution we present a tool environment 
supporting ViewPoint-oriented software development based on a formalization 
by distributed graph transformation. 



1 Introduction and Related Work 

In system design the various development stages are visited more than once and quite 
different notations and process models need to be integrated in order to satisfy the 
requirements of the different stakeholders’ views and their processes. It is therefore 
highly desirable to provide flexible conceptual means and related tool support for 
representing the various cooperating stakeholders’ views and process models. In this 
contribution we use the ViewPoints framework to represent such views and processes. 
In addition the ViewPoints framework involves to tolerate inconsistent information in 
related ViewPoints until it seems necessary or appropriate to check and (re)establish 
consistency — at least in some parts of the system [1]. The ViewPoints framework has 
been used quite successfully and has been documented in the literature [2, 1,4]. 

The question which is addressed here is how tool support can be constructed to ef- 
fectively represent the loosely coupled approach: some local development within a 
Viewpoint is followed by interaction with related ViewPoints via consistency checks. 

The approach of distributed graph transformation supports the idea of loosely cou- 
pled Viewpoints as outlined above quite naturally. It realizes the separation between 
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the independent development of single local ViewPoints and the configuration and 
connection of a set of related ViewPoints in a structured way. 

Distributed graph transformation which is based on the double-pushout approach to 
algebraic graph transformation is introduced formally in [6]. Using AGG [7] as a 
computing platform an adequate level of tool support can easily be constructed. The 
manipulation of representation schemes is expressed as graph transformation rules and 
the interaction and cooperation of distributed ViewPoints is adequately formulated as 
distributed graph transformation rules. As a result we gain tool support for ViewPoints 
and a corresponding formal presentation [5, 4]. As such it provides the possibility for 
formal analysis and most importantly a great deal of flexibility for integrating new 
Viewpoints. 

The Viewpoints framework was devised by A. Finkelstein et al. [2] to describe 
complex systems. An overview of other approaches related to multiple perspectives in 
software development can be found in [3]. In [1] a general overview wrt inconsistency 
management within the ViewPoints framework is given. 

In the chapter The ViewPoints Framework we introduce briefly our approach to 
ViewPoint-oriented software development. Based upon this we present tool support 
for our approach in the chapter The ViewPoint Tool. 

2 The Viewpoints Framework 

A ViewPoint is defined to be a locally managed object or agent which encapsulates 
partial knowledge about the system and its domain. It contains partial knowledge of 
the design process [2]. The knowledge is specified in a particular, suitable representa- 
tion scheme. An entire system is described by a set of related, distributable ViewPoints 
which are loosely coupled. 

A single ViewPoint consists of five slots. The style slot contains a description of the 
scheme and notation which is used to describe the knowledge of the ViewPoint. The 
domain slot defines the area of concern addressed by the ViewPoint. The specification 
slot contains the actual specification of a particular part of the system which is de- 
scribed in the notation defined in the style slot. The fourth slot is called work plan and 
encapsulates the set of actions by which the specification can be built as well as a 
process model to guide application of these actions. Two classes of work plan actions 
are especially important: In-ViewPoint check actions and Inter-ViewPoint check ac- 
tions are used for checking consistency within a single ViewPoint or between multiple 
Viewpoints, respectively. The last slot of a ViewPoint called work record contains the 
development history in terms of the actions given in the work plan slot. 

A ViewPoint template is a kind of ViewPoint type. It is described as a ViewPoint in 
which only the style slot and the work plan slot are specified, i.e. the other slots are 
empty. When creating a new ViewPoint, the developer has the opportunity to use an 
existing ViewPoint template instead of designing the entire ViewPoint from scratch. 

The Viewpoints framework is independent from any particular development 
method and actively encourages multiple representations. Software development 
methods and techniques are defined as sets of ViewPoint templates which encapsulate 
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the notations provided as well as the rules how they are used. Integration of methods 
and views is realized by such rules referring to multiple ViewPoint templates. 

A more detailed description of the ViewPoints framework and its formalization by 
distributed graph transformation is given in [4]. In the next section we now present a 
brief overview of tool support. 



3 The ViewPoint Tool 

The ViewPoint Tool comprises three main components: the ViewPoint manager, the 
template editor and the ViewPoint editor. While the ViewPoint manager serves as a 
central tool to coordinate all activities within using the ViewPoints framework, the 
template editor allows to design ViewPoint templates - i.e. styles combined with work 
plan actions - and the ViewPoint editor allows to work with specifications and work 
records of actual ViewPoints. All ViewPoints used in the ViewPoint editor have to be 
instantiated from existing ViewPoint templates developed by the template editor. 

The ViewPoint manager serves to organize all developed ViewPoint templates and 
all actual ViewPoints (cf. Figure 1). It is used as a starting point to enter the template 
editor and the ViewPoint editor. First ViewPoint templates can be created which then 
can be developed further within the template editor. Then actual ViewPoints can be 
instantiated from a template which are usable within the ViewPoint editor. 

The template editor allows to edit the work plan slot and the style slot of a View- 
Point template. All actions of the ViewPoint template’s work plan have to be modeled 
as graph transformation rules (cf. Figure 2). The ViewPoint editor allows to edit a 
ViewPoint instantiated from a ViewPoint template developed by the template editor. 
All actions defined in the corresponding template’s work plan can be applied to build 
an actual specification. Figure 3 depicts a ViewPoint editor window, the actual speci- 
fication is displayed on the left and all work plan actions are listed on the right. 




Fig. 1. ViewPoint manager window. 
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Fig. 2. The work plan window of the template editor. 
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Fig. 3. The Viewpoint editor. 

A more detailed description of the ViewPoint Tool - including distribution aspects 
and inconsistency management - is given in [7], 
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4 Conclusion and Further Work 

In this contribution we have sketched a brief introduction to the ViewPoints frame- 
work and the ViewPoint Tool environment. Various case studies modeling non-trivial 
applications (e.g., integration of architecture design and performance evaluation views 
[5]) have shown that our implementation meets all the requirements for supporting the 
multiple perspectives problem in a flexible ViewPoint environmet. The present ver- 
sion of the ViewPoint Tool is based on the local version of AGG [9]. Currently we are 
working on integrating the features of a prototype AGG version realizing distributed 
graph transformation. 
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Abstract. The usability of formal concepts for system design depends 
essentially on their integration in the design process. We discuss several 
possible levels of integration: technical integration of tools considering 
APIs and tool interfaces, conceptual integration of metamodels of de- 
scription formalisms combined with hard and soft constraints, semanti- 
cal integration of semantics of description techniques using a common 
semantic model, and finally methodical integration by an embedding in 
the development process. We show the feasibility of such an integrated 
approach and its advantages presenting AuTOFocus/Quest, a formal 
method CASE- Tool with its levels of integration. Parts of a banking 
system model are used as example. 



1 Introduction 

The need for development tools for the design of (embedded) systems has been 
widely accepted: several programs are available for their construction, often fo- 
cusing on specific aspects of the design process like building a data-model, ver- 
ifying system properties, or simulating a designed system. However, generally 
several of these aspects are important in a thorough design process. 

An obvious way to obtain a more powerful tool is to combine existing tools 
and to integrate them. This approach has also been applied to description tech- 
niques like the UML. However, the result of the integration is not necessarily 
satisfying for the user: There can be redundancies (with the possibility to intro- 
duce inconsistencies while modeling overlapping aspects of the system) , missing 
integration of concepts (with the need to bridge a gap between the design and 
the verification tool), or - as the most critical aspect - no integrated method for 
the user. These problems arise in conventional software development concepts 
as well as in formal method approaches. 

In this paper we advocate a new multi-level integration concept. The most so- 
phisticated level is the methodical integration, ideally based on the next level, the 
semantic integration of the used description techniques. The third level forms the 
conceptual integration of metamodels, followed by the lowest integration level, 
the technical integration of tools. Integration on all levels results into powerful 

* This work was supported by the Bundesamt fiir Sicherheit im Informationswesen 
(BSI) within the project Quest, and the DFG within the Sonderforschungsbereich 
342. 
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tools that provide a lot of features to the user. The layered integration hierar- 
chy makes it easy to connect other programs, provided that the development 
methods fit together. 

As an example for this new integration hierarchy we present the tool Auto- 
Focus/Quest, offering many different features, ranging from different graphical 
description techniques to theorem proving, testing, code generation and model 
checking. AuTOFocus/Quest integrates the CASE tool prototype AutoFocus 
with the formal tools VSE II, SMV, SATO, and CTE. This paper is structured 
as follows: after a short overview over the tool AuTOFocus/Quest in Section 2, 
we present (parts of) the banking system of the FM99 tool competition in Sec- 
tion 3 to introduce our description techniques. The main part of this paper 
(Section 4) describes the different levels of integration that are present in the 
AuTOFocus/Quest tool. We conclude with a comparison with other existing 
tools. 

2 The AuToFocus/Quest-Tool 

AuTOFocus/Quest has been presented successfully at the Formal Method World 
Congress 1999^. In the following we briefly describe the features of the tool. 

2.1 AutoFocus 

AutoFocus [HMS+98] is a freely available CASE- Tool prototype for the devel- 
opment of correct embedded systems. Similar to other CASE- Tools it supports 
graphical description of the developed system using several different views. Au- 
toFocus builds upon formal methods concepts. The available views are: 

— Interface and structure view: By using System Structure Diagrams (SSDs) 
users define structure and components of the developed system and the in- 
terfaces between components and the environment. 

— Behavior view: State Transition Diagrams (STDs) describe the behavior of 
a component in the system. 

— Interaction view: Extended Event Traces (EETs) capture the dynamic in- 
teractions between components (and the environment). EETs are used to 
specify test cases or example runs of the systems and have a Message Se- 
quence Chart-like notation. 

— Data view: (textual) Data Type Definitions (DTDs) define the data types 
for the description of structure, behavior and interaction diagrams. We use 
functional datatypes. 

All views are hierarchic to support descriptions at different levels of detail. Au- 
toFocus can check the consistency between different views using an integrated 
consistency mechanism. AutoFocus offers a simulation facility to validate the 
specifications based on rapid prototyping. 

^ AuTOFocus/Quest was acknowledged as the leading competitor in the tool compe- 
tition of FM’99. See http://www.fmse.cs.reading.ac.uk/fm99/ for more informa- 
tion. 
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2.2 Quest 

Within the project Quest several extensions to AutoFocus were achieved.^ 
The aim of the project [Slo98] was to enrich the practical software develop- 
ment process by the coupling existing formal methods and tools to AutoFocus 
in order to ensure the correctness of critical parts of systems. The combina- 
tion with traditional software engineering methods is achieved by specification- 
based test methods which facilitate the selection of reasonable test-cases for 
non-critical components. The tools developed within Quest translate the graph- 
ical concepts into other formalisms suitable for verification, model checking or 
testing (VSE [RSW97], SMV [McM92], SATO [Zha97], GTE [GWG95]) and 
support the systematic generation of test-cases. To provide an integrated, itera- 
tive development process (partial) retranslations from the connected tools were 
implemented, supporting visualization of counterexamples, generation of test 
sequences with input values, and the reimport of components that have been 
corrected during verification. The translations were realized using an API and a 
textual interface to AutoFocus. This allows to easily connect other tools using 
interfaces or generators. 



3 The FM99-Banking System 

In this section we briefly present parts of a model that was presented on the 
Formal Methods World Gonference 1999.^ The banking system example was 
used to compare different modeling methods and verification tools, presented at 
FM’99, on a competitive basis. 

The banking system contains a central (main host) and several tills (auto- 
mated teller machines) that are communicating independently with the central 
database. The connections from the central to the tills may be down. Among 
other requirements it has to be ensured that the amount withdrawn within one 
day does not exceed a maximum value. 

We modeled the banking system with the graphical description techniques 
from AUTOFOCUS/Quest. In the following sections we describe the main struc- 
ture of the system, some of the datatypes used, the behavior of the connection, 
and a possible interaction sequence from a connection and the central. 



3.1 System Structure 

We modeled the system with two tills and two connections. Since the connections 
have a specific behavior (i.e. they can be down), we modelled connections as 
components in the system. The structure of the system is described in the Fig. 1. 
The connections pass transactions (of type Info) from the tills to the central, and 
in the other direction connections report information to control the behavior of 

^ The project was carried out for the German “Bundesamt fiir Sicherheit in der Infor- 
mationstechnik” (Information Security Agency) (BSI). 

® See http://www4.in.tum.de/proj/quest/ for the full model. 
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Fig. 1. SSD for Banking System 



the till. The messages (of type Message) are defined in a DTD (see Section 3.2). 
Furthermore the connections have acknowledge channels to indicate the sender 
of a message that it has been sent successfully. The SSD shows the ports (little 
circles) of the components, the external ports, and the channels that connect 
these ports. 

Reusing port names^ in different components allows us to describe the be- 
havior of each connection with the same state transition diagram. For example 
the channel outl connects to the port out of Coimectionl. 



3.2 Datatypes 

As simple examples, we show the definition of two datatypes and a function 
(defined using pattern matching) used within the graphical views: 

data Message = Money (Int) I NoMoney I Balance I MailSent; 

data Transaction = TA(Action, Account) ; 

fun withdrawMoneyCTA (Withdraw (x) ,acc))=Money(x) ; 



3.3 Behavior 

The behavioral description of the system refers to the ports of the components 
defined by the SSD in Section 3.1. The behavior of both connections are described 
in Fig. 2. If there are no values on both channels (expressed by the input patterns: 
out? ; Answer?) the connection changes its state to reduce energy usage. This has 
been introduced to model the fact that connections sometime are down. If the 
connection is down and receives a value it moves to the state sleeping. If another 
value is received, then the connection is up, and ready to process the data. 

Port names are attributes of ports. 
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Answer?m;out?i;CAck!Present;CentralMsg!m;TillAck!Present;inp!i: 




3.4 Interaction Example 

To illustrate the interaction from the connections and the central we use the EET 
in Fig. 3. This is only one example trace of the behavior of the system. All mes- 
sages between two ticks (dashed lines) are considered to occur simultaneously. 



4 Integration 

In this section we describe the integrations within AUTOFOCUS/Quest. There 
are different integration layers: 

— methodical integration (on the development process level) 

— semantic integration (on the semantics level) 

— conceptual integration (on the metamodel level) 

— technical integration (on the tool level) 

The quality of an integration depends on the reached level, and on the quality 
of the underlying levels, for example a complete semantic integration is not 
sufficiently helpful for a user without tool support. 



4.1 Metamodel Integration 

In our view, integrated metamodels are essential for further integration. Meta- 
models can be applied to define a modeling language [Met99] and are increasingly 
used, for instance to define UML [B.JR97]. In the case of AutoFocus the syntac- 
tic aspects of the modeling techniques, like SSDs and STDs, are described using 
a metamodel. We use class diagrams as defined by the UML for the description 
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Fig. 3. Execution Example 



of metamodels. We consider it essential that the metamodels of different con- 
cepts of a modeling language are integrated into one metamodel since otherwise 
different modeling concepts do not fit together. We show this for the example of 
SSDs and STDs. 

Fig. 4 shows a simplified version of the integrated metamodel for SSDs and 
STDs. An SSD consists of components, ports, channels and relations between 
them. A component has a name, and can be decomposed in an arbitrary num- 
ber of subcomponents, and can belong to a supercomponent. This is needed to 
model hierarchic components. A component is a composition of ports and chan- 
nels. In the example of Fig. 1 the component Connection! has four output ports 
and two input ports and no channels. All channels in Fig. 1 belong to the com- 
ponent Banking System, the supercomponent of the shown components. Below 
the metamodel of SSDs is the metamodel of STDs. An automaton consists of 
one state, which may be hierarchic, as the component in the STD metamodel. 
Similar to the component a state has interface points and transition segments. A 
transition segment is a composition of a precondition, some input patterns, some 
actions and output patterns. See the example of Section 3 for an explanation of 
those elements. 

We now have two concepts, the concept of system structure diagrams and 
the concept of automatons. But how do they fit together? In many other tools 
there will be only an association from components to automata: the dynamic 
behavior of a component can be described with an automaton. But there is 
more. In our case the input and output patterns that belong to a transition 
segment are connected to the ports of the component to which the automaton 
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Fig. 4. Integrated Metamodel for SSDs and STDs 
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belongs. So an input to the automaton of component Connection! in Fig. 1 
can only come from the ports Answer or out restricting what is considered a 
correct model. Thus for specifying a new input pattern one might want to only 
choose from ports of the related component or to create a new port, which then 
automatically belongs to the related component. Note that the constraint, that 
a port belongs to the right component, is not modelled in the class diagram 
of Fig. 4. There, only the fact is expressed, that every input has a relation 
to an arbitrary port. The constraint that the automaton belongs to the same 
component as the ports of the input and output patterns, is expressed in a logical 
constraint that belongs to the metamodel. Up to now AutoFocus uses its own 
syntax for these expressions. However, a prototype exists using OCL [WK98], 
the constraint logic of UML [BJR97]. 

Beside the integration of the concepts of SSDs and STDs there are other 
concepts integrated in AuTOFocus/Quest. For instance, datatypes are modelled 
and used. In Fig. 4 attributes with types like term or type are shown. These 
are actually relations, like the ones from input and output to port, to classes 
in other parts of the integrated metamodel. So we do not only have different 
concepts, but we have merged them tightly together. But sometimes the user is 
handicapped by a very strict link between the different views of a system. So we 
tolerate the possibility that the model might be inconsistent at some stages of 
the development. For example, when specifying an SSD, it is sometimes desirable 
that datatypes can be used that are not yet defined. Thus, especially for the links 
between different concepts, we tolerate inconsistencies. Hard constraints like the 
need for a channel to have relations to a source-port and a destination-port may 
not be violated. 



4.2 Semantic Integration 

As with the conceptual level, where all system views are mapped onto a common 
metamodel, all description techniques are also mapped onto one semantic model. 
Thus, all descriptions are semantically integrated on the mathematical or the 
model level as sketched in the following subsection. However, this is a very low 
level of integration not suitable for system development. Instead we need to 
express the semantics of the described systems in terms of the techniques and 
actions performed by the user. The highest form of integration is achieved if the 
user can completely stay within the level of formalization used in the specification 
process so far, for instance, to SSDs, STDs, EETs, and DTDs, as described in the 
second subsection. However, this is not generally possible and thus other forms 
of integration adding new formalisms or techniques must be used as described 
in the last subsection. 



Semantic Model As already suggested by the STD description formalism, we 
use a stepwise computation mechanism to model the behavior of a system or 
component. Each step consists of two substeps: reading the input ports of a 
component and processing the input, and generating the output. After each step 
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the output of a component is transferred from its output ports along its channels 
to the input ports of the corresponding channels. The behavior of a component 
or a system is formalized by sequences of those steps. 

One of the major incentives in choosing this semantic model is its simplicity. 
Furthermore, it is compliant with other approaches - both from the engineering 
and the formal methods domain ~ that are widely accepted. The concept of step- 
wise, cyclic computations with unbuffered variables (channels) is, for example 
found, in programming languages for PLCs (programable logical controllers) as 
well as in TLA (temporal logic of actions) . This straight-forward yet expressive 
semantic model seems to be best suited for the domain of hardware oriented 
embedded systems compared to approaches using more complex concepts, for 
example state charts with the concept of OR- and AND-states. Nevertheless, 
other semantic models can be adapted to fit the basic principles of AutoFo- 
CUS/Quest, adding concepts like buffering channels suitable for other domains 
like telecommunication. 

Consistent Specifications As already mentioned on the conceptual level of 
the metamodel, during a development process inconsistencies in system spec- 
ifications may occur. This is especially the case using a view-based approach 
where the specification is simultaneously presented on different levels of abstrac- 
tion and spread over different aspects like structure (SSDs), behavior (STDs) or 
interactions (EETs). Then mechanisms must be offered to support the user in 
finding those inconsistencies. Those inconsistencies may occur on the conceptual 
level, for example if the type of a port does not meet the value sent on it. On the 
conceptual level those checks are comparably simple and can be carried out au- 
tomatically. However, even in the semantical level different inconsistencies may 
occur: 

Abstract vs. concrete behavior: As mentioned in section 4.1, a component 
(or system) may be realized by a number of subcomponents using an SSD. 
Accordingly, the system designer can assign behavior to both the component 
and its subcomponents using STDs. In the AUTOFOCUS/Quest development 
methodology the assignment of behavior to the ‘black box’ and ‘glass box’ 
view of a system is considered as a refinement step performed by the de- 
signer. Thus, it should be checked that the abstract component including 
its behavior is refined by the concrete subcomponents and their behavior 
given by their STDs. Since this is a refinement step, the concrete behavior 
must fulfill the requirements of the abstract behavior, or - in other words - 
any behavior exhibited by the concrete system must also be possible in the 
abstract version. 

Behavior vs. interaction: As mentioned in section 3 the views used in the 
AuTOFocus/Quest approach are not completely independent and may share 
common aspects. On the semantic level, both SSDs combined with STDs and 
EETs express behavior of a system (or component). 

Again, support is needed to aid the user during the development process in 
detecting such inconsistencies. Again, those checks should be performed as au- 
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tomatic as possible. If the state space of the specified system is finite, in gen- 
eral model checking can be used to perform those checks. We used the model 
checker /icke [Bie97] to implement a prototype of such an automatic check 
([SH99], [Bcc99]. Naturally, the performability of such checks is heavily influ- 
enced by the size and the complexity of such a system. For the second check, 
i.e., verifying that an interaction described by EET corresponds with the be- 
havior of a system characterized by SSDs and STDs, another proof method can 
be applied using a bounded model checking approach. Here, the model checker 
SATO is used to check that form of consistency (see [WimOO]). 

Further Integration As mentioned above, automatic checks can not always 
be performed. In that case, other forms of integration must used. 

One possible solution is to exchange the model checker by a theorem prover, 
as it was done with AuTOFocus/Quest using VSE. This integration adds a 
new description formalism, the logical formalism of the theorem prover, to the 
existing set of description techniques. Thus, this approach requires the user to get 
familiar with another formalism as well as an additional tool, the prover. While 
this results in a weaker integration from the user’s point of view, it extends 
consistency checks to more general systems with an infinite state space. 

Another possibility is to add another description formalism to express se- 
mantic properties of a component or system and integrate a suitable tool for 
this formalism. In AuTOFocus/Quest both SATO (see [WimOO]), and SMV 
(see [PS99]) were integrated. This approach adds a new description formalism, 
the temporal logic, and does not treat the inconsistencies mentioned in the pre- 
vious subsection. However, it offers two advantages for easy integration in the 
tool environment: 

— The checks can be performed automatically, thus - from the user’s point of 
view - there is no need for another tool. 

— The check either passes or results in a counter example expressed in form of 
an EET. Thus, besides the temporal logics, no other formalism is needed. 

4.3 Methodical Integration 

The last sections dealt with the integration of the semantical concepts behind the 
conceptual layer. Integrated and consistent semantics are not only a well founded 
basis but also a prerequisite for a continuous and straight-forward software de- 
velopment process. As a prime requisite to up-to-date system development, the 
AuTOFocus/Quest method covers the development process from the graphi- 
cal description of the system over system verification using theorem proving to 
code generation. Beyond that, however, the methodical integration of different 
software development concepts is essential for a successful tool integration. An 
adequate integration of different methods will make any integrational tool worth 
more than the single parts from which it was made. 

Generally, the development process is divided into phases like requirements, 
modeling, validation, prototyping, and test. In our approach, while each phase 
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may use different techniques, they all work on the same metamodel with a com- 
mon semantics. This enables the developer to switch between different phases 
like specification, verification, or testing, and the corresponding tasks without 
the need for complex manual transformations. Due to the versatility of the model 
based approach, there are no restrictions introduced by the model which compli- 
cate the combination of those tasks or integration of new methods in the process. 
The next paragraphs discuss the different phases in detail and show how they 
fit into the integrated metamodel and the given semantics. 

The requirements phase generally deals with informal documents and 
fuzzy specifications. We provide extended event traces (EET, see Section 2.1) 
that allow the specification of use cases as exemplary interaction sequences. 
EETs, an AutoFocus description technique, represent a first, generally incom- 
plete, specification of the system. 

In the next phase, the modeling phase, the skeleton of the system specifica- 
tion is enlarged and refined to get a more defined structure and behavior model. 
This is done by applying the AutoFocus development method (See [HMS'^98]). 
If one or more EETs already exist, it is also possible to derive the first version of 
the interface and the system structure from the axes and messages of the EETs. 

In the validation phase the following tasks are supported: 

— consistency checks (see Section 4.1), 

— simulation (see [HMS+98]), 

— model checking (see [PS99]), bounded model checking (see [WimOO]) and 

— theorem proving. 

AuTOFocus/Quest provides simulation of components. So, faults in the spec- 
ifications can be detected and located directly while the simulation is running. 
Beyond that, the simulation also generates system traces which are displayed as 
EETs and can be later used for conformance testing. 

In case of developing safety critical systems, validation by simulation is not 
sufficient. Often formal proofs are required to show the correctness of the spec- 
ifications. With model checking it is possible to prove safety critical properties 
of components automatically. Therefore model checking became very popular. 
Model checking does not only check properties as valid, but also produces counter 
examples if the property does not hold. If the model checker finds a counter ex- 
ample, it is retranslated and displayed as an EET. Abstraction techniques are 
a further example for a method integration. They extend the power of model 
checking to large and infinite systems (we use [Miil98]). Simple proof obligations 
are generated (for VSE) to ensure that the model checked property in the ab- 
stract system also holds in the concrete systems. The design task, to find correct 
abstractions, is supported within AuTOFocus/Quest. 

Besides the model checking approach, AuTOFocus/Quest also allows to 
translate the specification to a representation understood by the VSE system, a 
theorem prover for a temporal logic similar to TLA supporting hierarchic com- 
ponents like AuTOFocus/Quest [RSW97]. Within the VSE system a formal 
founded validation of the specification can be performed. It is also possible to 
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make small changes of the specification in the VSE system and the re-import to 
AuToFocus/Quest. 

Beside system validation AuTOFocus/Quest supports the test phase. Test- 
ing in AuTOFocus/Quest focuses on conformance testing between a specifica- 
tion and its manually coded implementation. The most challenging task within 
software testing is a tool-supported test case generation. Therefore we have inte- 
grated the classification tree editor GTE [GWG95] . The GTE allows the classifi- 
cation of arbitrary datatypes with trees and the selection of certain combinations 
as test input classes. The construction of the classification trees is assisted by the 
classification tree assistant (GTA) which can be set up individually. In Auto- 
Focus/Quest we generate the GTA from datatype definitions, system structure, 
and automata. So the tester does not need to start from scratch, but can use 
the suggested standard classifications. The classification tree method is com- 
bined with a sophisticated test sequentialization which computes test cases, i.e. 
sequences of input/output data. Test cases are coded as EETs. A simple test 
driver allows the execution of the generated test cases with Java components. 

The implementation phase is supported with Java and G code generators. 

A well done methodical integration of different software development me- 
thods does not restrict the development process but gives more freedom. In Au- 
TOFocus/Quest EETs play an important role in integration. EETs are a kind 
of multi-functional description technique. They serve as use cases, interaction 
description, counter examples, as well as test cases. 

4.4 Tool Integration 

In the previous section we have shown the methodical integration of the develop- 
ment process. Through the different phases of the development process we have 
to use different tools, like AutoFocus, model checkers, theorem provers and 
test tools. So we designed AuTOFocus/Quest not to be one monolithic tool, 
but rather to be a collection of different specialized tools which are based on the 
same integrated metamodel. One big advantage of having many different tools 
is, that they are small, easier to understand and to replace. One example for this 
is the connection to the model checkers SMV and SATO. You can use each one 
or both for AuTOFocus/Quest or we can build another connection to a new 
model checker, which replaces the other two connections. 

To link our tool-collection together we use a central repository with a con- 
ceptual schema, which is defined by the integrated metamodel. Every other tool 
can use the repository via an API. The API offers methods for e.g. importing or 
exporting a complete repository to a text file or to do some consistency checks 
on a model or a part of it. Note that the consistency checker bases on the core 
API, so that different tools to check the consistency of our models can be used. 

Since we would like to integrate other tools, we want to have a flexible meta- 
model, and we want to be able to change things in the metamodel or to add new 
concepts to the metamodel without having to recode the central repository and 
without the need to touch every tool even if it is not affected by the change. So 
the core repository, which offers an API to create, modify or delete objects, is 
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completely generated. As the core API the textual importer and exporter are 
generated [Mar98] . Thus we only have to change tools which are directly affected 
by the change. The generated core repository also ensures that our hard con- 
straints are not violated. Every programmer using the API can rely on the fact 
that the hard constraints are not violated in any model, making programming 
considerably easier. 

A common, well documented model is also important for integration of new 
tools. To connect a new tool to AuTOFocus/Quest directly the repository API 
or a translation from the model data in the repository to the data needed by 
the tool can be used. Consistency checks can be used to ensure some constraints 
that are a prerequisite for the translation. Besides this a retranslation of results 
or model changes to AuTOFocus/Quest might be needed. 

The spectrum of currently available tools in the field of embedded systems 
ranges from those tool focused on formal based design including verification 
techniques to tools concentrating on software engineering aspects including view- 
based system description, code generation and simulation. Consider, for example. 
Atelier B [Abr96] on the one hand, StateMate [Har90] or SDT [Tel96] on the other 
hand. Generally, those tools only partially integrate those aspects. An integrated 
combination of clearly defined but simple modeling concepts, an underlying well- 
defined semantic model for verification purposes, industrial-oriented notations 
supporting view-based development, prototyping for requirements validation, 
code generation for system implementation as well as test cases generation for 
system validation. 

On the SW-engineering side, this is often due the fact that system modeling 
approaches like UML [BJR97] using different, graphical notation for the descrip- 
tion of systems lack a sound conceptual and semantical basis. As a consequence, 
in many cases tools like Rational Rose [Rat98] and Rhapsody [i-L97] supporting 
this notation are missing a suitable formal semantics. Thus, while those nota- 
tions and tools do offer support for checking syntactic consistency conditions, 
no such support is available on the semantic side. Those observations even hold 
for notations and tools based on more formally defined approaches like SDL and 
corresponding tools like SDT [Tel96]. 

On the other side, tools originating in formal approaches like STeP [BBC“*"95] 
or Atelier B [Abr96] often lack methodical or engineering functionality like the 
splitting of complete system descriptions into well-defined views of the system, 
combining these descriptions on different levels of abstraction as well as relating 
those views to form a consistent description. 

The goal for developing AutoFocus was not to build another tool but rather 
to investigate how the experiences gained in several basic research projects could 
be consequently applied to the development of embedded systems. Some aspects 
were considered as major topics: the use of well-defined description techniques, 
the modularity and expressiveness of those description techniques supporting 
different levels of abstractions and view-points, as well as the methodical inte- 
gration of those techniques for integrated development approach. Those aspects 
also are the features distinguishing AutoFocus from other tools in this area. 
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For example, approaches like StateMate mix different views (system structure 
and behavior by using AND- and OR-states). Furthermore, there a semantical 
basis is not applied to support model checking or theorem proofing. While other 
tools avoid those mixing of aspects, they are somewhat lax in the use of complete 
and clearly defined description techniques. Thus, for example, in ObjecTime, the 
diagrams for behavioral description are annotated with program code fragments 
to for a complete description. Since ROOM [SGW94] and ObjecTime were de- 
veloped without a clear semantical model, in the end the meaning of diagrams 
is only described by the generated executable models, leaving the possibility for 
open questions concerning modeling concepts as well as lacking the requirements 
for formal support by theorem proofing or model checking. 

The combination of the above mentioned aspects and the resulting method- 
ical consequences are central incentives for the development of AutoFocus. 
AutoFocus supports a lean subset of description techniques based on a com- 
mon mathematical model. These description techniques are independent of a 
specific method or a tool, while offering the essential aspects of similar descrip- 
tion techniques, and can therefore be combined with a wide rage of methods and 
development processes. 

5 Conclusion and Future Work 

Integration of formal techniques is more than just integrating formal (and semi- 
formal) tools; nevertheless, tool integration is one important step. Several tool 
platforms that can be readily connected to AuTOFocus/Quest, including Nu- 
SMV, Proovers, STeP, or Isabelle. Since the ultimate goal is the methodical in- 
tegration, more steps have to be taken on this level: Code generators for C and 
Java are currently under development. Further work is needed in requirements 
phase, to support methods for requirements tracing (as found in the DOORS 
tool). Furthermore, in the modeling phase the use of graphical support for model 
based development steps (refinement, splitting of transitions, combining chan- 
nels, etc.) in AutoFocus must be investigated. 
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Abstract. Formal specification and verification techniques can improve 
the quality of programs by enabling the analysis and proof of seman- 
tic program properties. This paper describes the modular architecture 
of an interactive program prover that we are currently developing for 
a Java subset. In particular, it discusses the integration of a program- 
ming language-specific prover component with a general purpose theorem 
prover. 



1 Introduction 

Specification and verification techniques can improve the quality of programs by 
enabling the analysis and proof of semantic program properties. They can be used 
to show the absence of exceptions and to prove that a program satisfies certain 
interface properties or a complete interface specification. This is particularly 
interesting for the emerging market of software components. As we illustrate in 
Section 2, tool support is crucial for the application of such formal techniques. 

The paper motivates and describes the modular architecture of an interactive 
program prover that we are currently developing for a Java subset. In particular, 
it discusses the integration of a programming language-specific prover component 
with a general purpose theorem prover. The goal of this research is to provide a 
powerful and flexible tool that 

— supports complete a posteriori program verification; 

— provides assistance in top-down program development, e.g. for deriving spec- 
ifications of auxiliary procedures; 

— allows one to specify and check certain simple, but in general undecidable 
properties, such as the absence of null pointer dereferencing and out-of- 
bounds access to arrays. 

As illustrated by the last aspect, we are not only interested in algorithm ver- 
ification, but as well in showing the absence of certain (language dependent) 
program errors. In particular, we have to deal with sharing and abstraction. We 
build on an object-oriented language, because it supports encapsulation on the 
level of types and because subtyping simplifies reuse. 

Overview. The paper is organized as follows. Section 2 provides the techni- 
cal background for specification and verification, motivates our approach, and 
discusses related work. Section 3 presents the overall architecture for the interac- 
tive verification environment. Section 4 focuses on the realization of the program 
prover component and describes its application by an example. 
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2 Verification of Realistic Programs 

Verification of realistic programs is a fairly complex task. The goal of this section 
is to illustrate where this complexity comes from and to give an overview of 
tool-based approaches to cope with this complexity. The first subsection sketches 
state-of-the-art specification techniques and the involved formal background that 
has to be mastered by verification tools. The second subsection summarizes 
mechanical approaches to formal program verification from the literature. 



2.1 Specifying Object-Oriented Programs 

Program specifications should describe the behavior of program components 
in a formal and abstract way: Formality is a prerequisite for computer-aided 
verification. Abstraction is needed to achieve implementation independency and 
to simplify verification. In the following we summarize formal techniques to 
achieve abstraction in 00-languages. 

We build on the Larch approach to program specification (cf. [GH93]) that 
uses type invariants and pre- and postconditions for procedures/methods. The 
following Java program fragment shows an interface type Set^ and an imple- 
mentation of this type based on arrays. 

interface Set { class ArraySet implements Set {. 

boolean add( Object o ); private Object [] elems; 

boolean containsC Object o ); private int setsize; 

int sizeO; boolean add( Object o ){ ... } 

... } ... } 

Since the interface Set may have several implementations and since it should 
be possible to modify implementations without changing the specification, the 
specification of Set cannot refer to any implementation parts, i.e., it has to be 
given in abstract terms. We specify the behavior of type Set using an abstract 
data type with main sort SET and the usual operations, and an abstraction 
function aSet. aSet maps a Set object X and an object store to a value of sort 
SET. The object store is needed to capture the objects referenced by X. Method 
add can thus be specified as follows where $ is a variable denoting the current 
object store and the caret-operator yields the value of a variable in the prestate: 

boolean add( Object o ) 
pre o / null 

post result — {o G aS et {this, $")) A aS'et (this, $) = {o} U aSet{this,$') 

A VObjectA: -^inRepSet{X, this, $") => unchanged {X,$,$") 

The first conjunct of the postcondition states that add yields true if and only if 
the object to be inserted is already contained in the set. The second conjunct 
specifies that after execution the implicit parameter this refers to the enlarged 
set. The third conjunct describes that the states of all objects not belonging to 
the representation of the input set remain unchanged. The representation of an 

^ A simplified version of the Set type as contained in the Java library. 
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abstract value comprises all objects that are used to represent the value in the 
object store. Since abstraction functions and the predicate inRepSet depend on 
implementations, they have to be explicitly defined. E.g., the provider of class 
ArraySet has to define an abstraction function and the predicate inRepSet for 
objects of type ArraySet. (For a set represented by an Array Set-object Y, the 
representation consists of Y and the referenced array object.) 

The above example illustrates the basic aspects needed in a realistic frame- 
work for formal program specification and verification. A more detailed pre- 
sentation of the specification techniques can be found in [PH97b,MPH99]. In 
summary, such a framework has to provide the following features: 

— To express abstraction, it is necessary to define and reason about abstract 
data types that are specified outside the programming language (e.g. SET). 

— To specify modifications of the object store and to formulate properties on 
the program level (e.g. absence of null pointer dereferencing), a formalization 
of objects and the object store has to be provided by the framework. 

— The abstract and program levels have to be integrated to be able to spec- 
ify abstraction functions, representation predicates, and abstract data types 
that are based on types of the programming language (e.g. the abstract data 
type SET refers to elements of type Object). 

The Java interactive verification environment Jive that is described in this 
paper supports all of the above features (cf. Section 3 and 4). 



2.2 Computer-Aided Program Verification 

In the literature, we can essentially find three approaches to computer-aided 
program verification. 

Verification Based on Language Semantics. This technique works as follows: 
Translate the program into a general specification framework (e.g. HOL) in 
which the semantics of the programming language is defined. Then state the 
program properties directly within this framework and use the rules of the lan- 
guage semantics for verification. This techniques is e.g. applied in [JvdBH’^98]. 

The advantage of this approach is that existing frameworks equipped with 
powerful tools can be used without extensions (e.g., PVS [COR+95] or Is- 
abelle [Pau94]). Only the translation process has to be implemented (and veri- 
fied). The main disadvantage is that specification and verification on the seman- 
tics level is very tedious, because the abstraction step gained by an axiomatic 
language definition once has to be done in semantics level proofs again and again. 

Verification Condition Generation. VCG was the classical approach to program 
verification. Based on a weakest precondition semantics, a program specification 
is transformed into a (weakest) precondition formula guaranteeing that a pro- 
gram satisfies its postcondition; i.e., program dependent aspects are eliminated 
by the wp-transformation. The precondition formula (verification condition) can 
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be proved by a general theorem prover. This is the technique used in systems 
like e.g. the Standford Pascal Verifier [Com79]. 

The advantage of this approach is again that program dependent aspects are 
eliminated automatically and that the proper verification task can be done using 
standard tools. The disadvantage is that in realistic settings (cf. Section 2.1) the 
verification conditions become huge and very complex. There are essentially 
three reasons for that: (recursive) procedure/method calls, aliasing operations 
on the object store, and abstraction. As an example, consider an invocation site 
of method add of interface Set. If we use the specification of add to compute 
a weak precondition for a formula Q, the resulting precondition has about the 
size of the method specification plus the size of Q. The reason for this is that 
the postcondition of add does usually not match Q and that simplification is not 
trivial. Having several method invocations in a statement sequence easily leads 
to unmanagable preconditions. 

Working with verification condition generation has two further disadvantages: 
a) If the generated condition cannot be proved, it is often difficult to find out 
why this is the case and which program statement causes to fail (cf. [GVIP90] 
for a discussion of this issue), b) VCG is fairly indexible and only applicable in 
an a-posteriori verification. E.g., in top-down program development, one would 
like derive the needed properties of a used method from the specification of the 
calling method. 

Interactive Program Verification. Interactive program verification applies ideas 
from general tactical theorem proving to programming logics like e.g. to Hoare 
logic (see below) or dynamic logic (cf. [Rei95]). The main advantage of this ap- 
proach is that program proofs can be developed around the program, i.e. as 
annotations to the program. The intuition about the program can be directly 
used for the proof. Strengthening and weakening steps can be applied where 
most appropriate. In particular, such steps can be done before and after method 
invocations to adapt method specifications to the needs at the invocation site. 
This way the described problem of VGG can be avoided. In addition to this, it is 
usually easy to detect program errors from failing proofs. Furthermore an advan- 
tage is that the interactive program prover “knows” the programming language 
and can provide appropriate views. On the other hand, a language dependent 
program prover has to be developed which is quite an engineering challenge. 

Because of the described disadvantages of the first and second approach, 
we decided to construct an interactive, tactical prover for program verification. 
Within this prover, weakest precondition techniques can be implemented by 
tactics and used where appropriate without giving up flexibility. Depending on 
the goals, other combinations of the verification approaches sketched above are 
investigated in the literature. E.g. in [Gor89], Gordon demonstrates the devel- 
opment of programming logics based on a general HO-theorem prover showing 
the strength of HO-reasoning. However, he cannot exploit the specific relation 
between programs and program proofs. In the Extended Static Ghecker for Java 
(ESG/Java, cf. [DLNS98]), the translational approach is combinded with VGG 
for automatic checking of a restricted class of specifications. 
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3 An Architecture for Interactive Program Provers 

This section presents our architecture for interactive program provers. The ar- 
chitecture is based on the following requirements: The functional properties as 
described in Section 2.1 have to be fulfilled. The newly implemented program 
prover component should only be responsible for proof tasks that are directly 
related to the program. General specification and verification aspects should be 
delegated and performed by state-of-the-art theorem provers. This comprises in 
particular the definition of the object store and abstraction functions. In the 
following, we first analyse the consequences of combining general provers with 
language-specific provers. Then, we explain the overall architecture. 

Communicating Provers. There are two architectural alternatives for com- 
bining a general prover and a programming language specific prover component 
within a verification system: a) The general theorem prover is encapsualed by 
the system and hidden to users, b) Both prover components are accessible by 
users and the communication between them is visible. For the following reasons, 
we decided for the second alternative. It provides more flexiblity and is easier 
to react to new developments w.r.t. the general theorem prover. The implemen- 
tation is less expensive. For third party users, the programming interfaces of 
existing theorem provers are not sufficiently powerful to control all prover op- 
erations by an external process. The disadvantage of this solution is that users 
of the resulting system have to handle two interactive components: the program 
prover component and the theorem prover component. 

The communication between 
the two prover components is il- 
lustrated in Figure 1. The pro- 
gram prover sends type checking 
and proof requests to the general 
theorem prover. Type checking 
of pre- and postformulas is done 
in the general theorem prover, as 
these formulas contain logical variables and make use of abstract data types spec- 
ified as theories in the syntax of the general theorem prover. Proof requests result 
from strengthening and weakening steps in program proofs. They are formulas 
not refering to a special program part and are verified online or offline in the the- 
orem prover component. The information whether such proof obligations have 
been proven or not is sent back to the program proof component. This way, the 
program proof component can check whether program proofs are complete. 

The communication between program prover and theorem prover is based on 
a communication interface that allows one to send formulas from the program 
prover to the theorem prover. Type check requests differ from proof requests 
in that they are usually^ solved automatically whereas proof requests typically 
need user interaction. 




Fig. 1. Basic prover components. 



^ The subtyping of the used specification language (PVS) is in general undecidable. 
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The Jive Architecture. This subsection describes the overall architecture 
of Jive. Jive supports the sequential kernel of the Java language including 
recursive methods, classes, abstract classes, interfaces, thus inheritance and sub- 
typing, static and dynamic binding, aliasing via object references, and encap- 
sulation constructs. Exception handling and some of the predefined data types 
(in particular float and char) are not yet supported (cf. [MPH99] for a precise 
description). In addition to the Java subset. Jive supports annotations like that 
shown in Section 2.1. The common language for programs and annotations is 
called Anja (annotated Java). In the following, we explain the architectural 
components and the input sources of proof sessions based on the overview given 
in Figure 2. 



Anja Prelude Program to prove 




C ♦ D: D imports PVS theory from C 



Fig. 2. The Jive architecture 

System Components. The architecture is based on five components: 1.) The 
syntax analysis component that reads in and analyzes annotated programs and 
generates the program proof obligations. 2.) The program information server 
that makes the static program information gathered in the analysis phase avail- 
able to other parts of the system. 3.) The program prover component managing 
the program proofs. 4.) Views to visualize program proofs and to control proof 
construction. 5.) The theorem prover to solve program independent proof obliga- 
tions. In our current implementation, we use PVS for general theorem proving. 

The program proof component encapsulates the construction of program 
proofs. It provides two things: (1.) A container which stores all information 
about program proofs and (2.) an interface which provides operations to create 
and modify proofs within this container. Since the content of the proof container 
represents the program proof state, it is strongly encapsulated to the rest of the 
system. Modifications of the proof state can only be achieved by operations of 
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the container interface (see Section 4). Therefore correctness of proofs is ensured 
by the correctness of the basic container operations. 

During program proof construction, various information about the underly- 
ing program is needed by the program proof component: The structure of the 
abstract syntax tree, results of binding and type analysis, and the program un- 
parsing for visualization. This kind of information is provided by the program 
information server. In contrast to a compiler frontend, all information computed 
during static program analysis has to be available online after the analysis. 

Proof Setup. The verification of a program is based on three formal texts: 
1.) The PVS prelude containing two parts: (a) the formalization of the object- 
store; (b) the specification of abstract data types used in program annotations. 
Whereas the former part is program independent, the latter may be program 
dependent. 2.) The Anja prelude containing the specifications of predefined 
and library classes and interfaces. 3.) An Anja program, i.e. a program in our 
Java subset together with a suitable interface specification. Annotations are for- 
mulated in a language based on the specification language of the underlying 
theorem prover, i.e. PVS in our case. As illustrated in Section 2, they may refer 
to program variables and use abtract data types specified in the PVS prelude. 

From the described sources, the syntax analysis component generates three 
things: 1. The program proof obligations which need to be proven to guaran- 
tee that the program fulfills its specification. They are entered into the proof 
container. 2. Program dependent theories formalizing some of the declaration 
information of the program for the theorem prover. 3. The abstract syntax tree 
decorated with information of the static analysis. It is managed by the program 
information server. 

After syntax and static analysis, the system is set up for interactive proof 
construction. The user constructs program proofs using basic proof operations 
and tactics (see Section 4). The views and controllers provide access to the 
proof state. Program independent proof obligation are verified with the general 
theorem prover. The program prover monitors the overall proof process and 
signals the completion of proof tasks. 

4 The Program Prover 

Program proofs in Jive are based on a Hoare logic for object-oriented programs 
(cf. [PHM99]). Hoare logic is sufficient for our purposes and enables us to visual- 
ize proof parts as program annotations. This section first describes how the basic 
proof operations of the proof container are derived from the logic and how tac- 
tics can be formulated. Then, it explains the user interface for proof construction 
and visualization and sketches a simple proof done within Jive. 

4.1 Mechanizing the Programming Logic 

As the supported programming language provides recursive methods, the Hoare 
logic deals with sequents of the form A F { P } comp { Q } where A denotes a 
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set of method specifications (the assumptions) , P and Q are first-order formulas, 
and comp denotes a statement or a method, the so-called program component of 
the sequent. Program components are represented by references to the abstract 
program syntax tree. A rule in the logic consists of a finite number of antecedents 
and a sequent as conclusion. The antecedents are either sequents or first-order 
formulas. Rules without antecedents are called axioms. As examples, we show the 
rule to verify if-statements and the assumpt-intro-rule to introduce assumptions: 

A b { e A P } stmtl {Q}, AI-{-'eAP} stm2 { Q } A b A 

A b { P } if (e) { stml } else { stm2 }{Q} Ao,AbA 

Basic Proof Operations. As usual, proof trees are constructed from rule in- 
stances. A tree node has as many children as the rule has antecedents. There are 
two ways to construct proof trees. 1. A forward proof step takes several proof 
trees and combines them with a new root node. 2. A backward proof step adds a 
new node to one of the leaves. A proof tree is closed if all leaves are instances of 
axioms or first-order formulas that are proved by the theorem prover component. 

To gain the flexibility explained in Section 2, Jive supports operations for 
forward and backward proof steps. These operations have to be distinguished, 
because different directions require different context checks for formulas, pro- 
gram components, and parameters. The if-rule serves as an example: Forward 
proving combines two proof trees 5i and S 2 to a new proof tree, backward prov- 
ing refines a proof goal Q of an if-statement into two subgoals for the then- and 
else-branch. The context conditions of the ifjorward and ifJiackward operations 
are as follows: 



Forward Proof: 

1. 5i and S 2 have to be roots of proof trees. 

2. The assumptions of 5i and S 2 have to be equal. 

3. e has to be a conjunct of 5i. 

4. -ie has to be a conjunct of 1 S 2 . 

5. The preconditions of <Si and S 2 have to be equal 
modulo the conjuncts e and -te resp. 

6. The postconditions of 5i and S 2 have to be equal. 

7. stmtl and stmt2 have to be the then- and else- 
branch of the same if-statement. 



Backward Proof: 

1. 5 has to be the leaf of 
a proof tree. 

2. The program compo- 
nent of Q has to be an 
if-statement. 



Proof operations are executed as follows: First, the context conditions are 
checked. If they are met, the proof operation is applied and leads to a new proof 
tree, and thus to a modified state in the proof container. Otherwise, an appropri- 
ate exception is raised that can be used in tactics (see below) . Because operations 
first check all necessary context conditions, correctness of proofs is provided by 
the correctness of operations. The Jive system is currently based on a Hoare 
logic with 26 rules and axioms. Thus, it provides 52 basic proof operations. In 
addition. Jive provides a cut operation to remove, a copy operation to copy, 
a paste operation to combine proof tree parts, and operations to inspect parts 
of the proof tree or to navigate within proof trees. These operations allow for 
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comfortable interactive work with program proof information, e.g., they enable 
one to cut off failing proof parts. 

Tactics. Program proofs are constructed by successively using proof operations 
as described above. To simplify proof construction, sequences of proof operations, 
e.g. to apply a weakest precondition strategy, can be combined to form tactics. 
As an example, we show a tactic that eliminates the assumptions of an open leaf 
of the proof tree by iterating the assumpt-intro-rule unless all assumptions are 
eliminated^. Since the proof operations of Jive are implemented in Java (see 
Section 4.4), tactics are formulated as Java programs invoking proof operations. 
The getPreO, getPostO, and getCompO operations return the precondition, 
the postcondition and the program component of the triple t: 



public Proof TreeNode eliminate_assumptions (Proof Container c, 

ProofTreeNode ptn) throws ContextException f 
Enumeration e = ptn.getAssumptionsO .elementsO ; 
while (e .hasMoreElements () ) { 

Triple t = (Triple)e.nextElementO ; 
ptn = c . assumpt_intro_backward( 

ptn, t . getPreO , t . getCompRef () , t.getPostO ); 

} 

return ptn; 

} 



4.2 User-Interfaces of the Program Prover 

Interactive program proof construction with proof operations enforces users to 
work explicitly with several kinds of information like formulas, program struc- 
tures, textual program representation, etc. A graphical user interface is required 
(1.) for an appropriate visualization of the proof state and of the related informa- 
tion as well as (2.) for convenient selection, input, and application of operations 
and tactics. Currently Jive provides a so-called tree view and a text view to 
program proofs^. Of course, both views can be used together within one proof. 

Tree View. The tree view (Figure 4 shows a screen shot) presents the information 
contained in the proof container in a graphical way. All parts of proof trees can 
be examined, selected, copied, combined, extended and deleted. Compared to 
the text view (see below), the tree view shows all details of proof trees. In 
particular, it enables the user to inspect proof steps that cannot be presented as 
proof outlines and shows the complete proof structure. It supports the structural 
operations on trees (cut, copy, paste) and proof operations that take several trees 
as arguments which are not related to one program component. Since proof trees 
are in general large structures, tree views enable to work with scalable clippings 
of trees, i.e., the user interface displays only relevant information. 

® Applying the assumpt-intro-rule backward eliminates an assumption. 

^ At time of submission of this paper, the text view was still under construction. 
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Text View. To provide a more compact view to program proof information and 
to enable an embedding of program proof information into the program text, text 
views display selected proof information within a textual program representation 
(Figure 3 shows a screen shot). This technique is based on so called proof outlines 
(cf. [Owi75]). The text view allows the user to consider proofs (or at least most 
of the central proof steps) as annotations to the program text. This turns out 
to be very helpful for interactive program proofs as the program structure is 
well-known to the user and simpler to handle. In particular, it allows the direct 
selection of program components which is needed for forward proofs. In addition 
to this, well-designed proof outlines are a good means for program and proof 
documentation. 



4.3 Using the Program Prover 

In this section, we illustrate the use of the program prover by an example explain- 
ing in particular the interaction of automated and manual proof construction. 
Using an interface of a singly linked integer list, we want to prove a simple 
recursive sort method: 



interface List { 
public List restO 
pre aL(this,$) = L; 
post aL (result,!) = rst(L) 
AND result /= null; 
pre $=QS; 
post $=QS; 



class Sort f 

public static List sort (List 1) 
pre l/=null AND L=aL(l,$); 
post aL(result , $)=a_sort (L) ; 

{ 

List Iv.res; 
boolean bv; int ev; 



public int first () 
pre aL(this,$) = L; 
post al(result) = fst(L); 
pre $=QS; 
post $=0S; 

public boolean isemptyO 
pre aL(this,$)=L; 
post aB (result) =isempt (L) ; 
pre $=0S; 
post $=0S; 



} 



bv = 1 . isemptyO ; 
if (bv) res = 1; 
else "C 

Iv = l.rest();ev = l.firstO; 

Iv = Sort . sort (Iv) ; 

res = Sort . sortedins (ev, Iv) ; 

} 

return res; 

} 

static List sortedins (int e. List 1) 
pre aL(l,$)=a_sort(L) AND aI(e)=E 
AND l/=null; 

post aL(result,$) = a_sort (app(E,L) ) ; 
{ ... } 



In the given Anja source, we use logical variables (written with capital let- 
ters) to bind values in the precondition for use in the postcondition. Each list 
method is specified by two pre-post-pairs. The first pair expresses the functional 
behavior using the abstraction function aL mapping objects to an abstract list 
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data type. The second pair states that each method does not change the object 
store. Method sort of class Sort implements insertion sort using sort Ins as 
auxiliary method; a_sort sorts an abstract list. We sketch the proof of method 
sort assuming the correctness of the list interface, sort is a static method, 
i.e. behaves like procedures in imperative languages. The logical aspects of dy- 
namic binding cannot be discussed here (cf. [PHM99]). Starting the Jive system 
with the given example yields the following two proof obligations for methods 
sort and sortedins: 




We start the verification of sort by applying the SWP-tactic to the goal 0. 
This tactic realizes a simple weakest-precondition-strategy. For the example, it 
reduces the method specification to a pre-post-pair for the statement sequence 
in the body. In our logic, this corresponds to two elementary proof steps that 
in particular conjoin “this yf null” to the precondition. Then, the SWP-tactic 
tries to verify the resulting pre-post-pair by forward proof steps starting with 
the rightmost innermost statement (according to the AST of the program), i.e., 
it starts at the end of the program text and works to the beginning. In our 
case, it automatically handles the return-statement and the then-branch of the 
if-statement. In the else-branch, it cannot procede because the postcondition 
of the if-statement does not match the postcondition of the specification for 
sortedins. The corresponding proof state is illustrated by the screen shot of the 
text view in Figure 3. The system uses colors to distinguish program text from 
annotations and open proof slots (red) from verified triples (green) . In the figure, 
this is indicated by brackets left to the screen shot. The red triple corresponds 
to the open leaf of the overall proof. The two green triples correspond to needed 
proof parts that have been constructed by the SWP-tactic. 

The proof state after termination of a tactic can be interactively manipulated 
by the user. He or she can add further proof parts using other tactics or basic 
proof operations and then rerun the original tactic on the original goal. Typically, 
user interaction is necessary at method invocation sites, because there may be 
more than one specification for a method and it is not obvious which of them 
has to be used or how they have to be combined. How to handle such situations 
is demonstrated with the invocation of method first in the example. We show 
three states of a forward proof: 1. After instantiating the method specifications 
at the invocation site (one basic proof step). 2. After conjoining the resulting 
triple (one basic proof step). 3. After adding of an invariant term (one basic proof 
step) and eliminating the logical variable OS (several basic proof steps, done by 
a tactic). For space reasons, we leave out the surrounding window context: 
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• State 1: 



• State 2: 



• State 3: 



{l/= 


nu 


II AND aL(l, $) = L } 9 


{l/= 


nu 


II AND $ = OS } 10 




ev 


= 1 .fi rstO ; 


{$ = 


OS 


} 10 


{ al(ev) = 


fst(L) ) 9 



{ 1 /= null AND aL(l, $) = L AND 1 /= null AND $ = OS } 1 1 
ev = 1 .fi rstC) ; 

{ al(ev) = fst(L)AND $ = OS } 1 1 


( 1 /= null AND aL(l, $) = L AND aL(lv, $) = rst(L) } 2 0 
ev = 1 . fi rstC) ; 

{ al(ev) = fst(L) AND aL(lv, $) = rst(L) } 20 





The other method invocations in the else-part of method sort are processed 
accordingly. The overall proof of method sort is constructed by approx. 90 basic 
proof operations where currently 20 of them are performed by tactics; 10 mostly 
trivial implications from weakening and strengthening remain to be verified by 
the general theorem prover. The tactics are still fairly primitive. With improved 
tactics and a refined specification technique, we aim to drastically reduce the 
amount of needed user interaction. 



File Edit Axioms Forward Operations Backward Operations Control Strategy 
Nativesljclear SelectionllLogical Variables! 




Fig. 3. The text view after applying the SWP-tactic. 



The presented example shows three important aspects of the system: 1. For- 
ward and backward proving is combined to gain the flexibility needed to encode 
typical proof strategies. 2. User-guided and automated proof construction by 
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tactics can be freely mixed so that automation can be done where possible and 
user interaction can focus on the critical points. 3. Different views are needed 
that allow one to inspect the proof parts on different levels of abstraction. Even 
in the simple example, there exist up to 7 proof fragments at one time with 17 
open proof slots and proof tree depth up to 20. This amount of information is 
conveniently abstracted by the text view. If detailed information is needed, the 
user can refer to the tree view (see Figure 4). 




Fig. 4. A clipping of the proof tree view 

4.4 Technical Issues 

This section describes implementation issues concerning the Jive system. 

System Implementation. As shown in the table below, the Jive system is im- 
plemented using a variety of tools and languages, mostly Java. Java combines 
several necessary properties, which are useful to implement heterogeneous tool 
environments. In particular, we make use of the Java Native Interface for C, of 
the API for TCP interfaces to connect to the theorem prover, and of the Swing 
library as graphical user interface. The central program proof component with 
the proof operations (as Java Methods) and auxiliary implementations parts 
such as formula handling is completely implemented in Java. Tactics are imple- 
mented as Java classes and can be dynamically loaded into the system. All other 
components are attached using the above mentioned interfaces. 

Generative reuse teehniques. One major design decision was to use as much 
as possible generative techniques to implement the system. This is possible 
because many subtasks to be solved are directly derived from compiler con- 
struction. 1. We use flex and bison for the syntax analysis of Anja programs. 

2. The program information server is based on attributed abstract syntax trees 
for programs and annotations. It is generated by the MAX tool (cf. [PH97a]). 

3. ANTLR [PQ95] is a compiler generation tool for Java and is used to examine 
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the structure of formulas given as arguments to proof operations. ANTLR is 
used as it can directly produce Java objects as output. 

Integration of the PVS Theorem Prover. As explained above, Jive uses PVS 
for type checking and for the verification of non-Hoare formulas. We use the 
techniques described in [But97] for the communication between PVS and the 
program prover. The connection to the proof system is implemented as a TCP 
connection with the PVS host system Emacs. Because of restrictions in the 
interface of the PVS system, our current implementation enforces that the user 
acknowledges in PVS that a proof obligation sent by the program prover has 
been received. Support for asynchronous communication would be desirable to 
reduce the need for user interaction. 

Implementation State and Further Work. The current version of Jive enables 
one to verify specified program properties of Anja programs as described in Sec- 
tion 3 and 4. We implemented tactics to support weak precondition reasoning 
for statements and tactics for simplifying method calls. As further implemen- 
tation steps we consider: 1. The development of more powerful tactics to make 
reasoning more comfortable. 2. Improvements of the user interface, in particular 
of the text view. 3. Enhancements to the programming logic, in particular for 
exception handling. 



Tool /Language 


Lines of code 


Java code 


13078 


MAX specification 


2524 


C Code 


1768 


flex & bison specification 


1218 


ANTLR specification 


854 


Emacs lisp code 


274 


PVS standard prelude for Jive 


482 


Anja standard prelude for Jive 


158 



5 Conclusion 

Verification of program properties for object-oriented programming languages 
requires tool support, because the formal framework can hardly be handled by 
hand. In this paper, we presented the architecture of the interactive program 
verification environment Jive. Jive combines properties of different approaches 
to software verification. It divides program proving into a program proving and 
a theorem proving task. This enables the use of existing theorem provers for the 
proof steps that are not related to the program. For the program proving tasks, 
we described a technique to implement a given Hoare logic by basic proof opera- 
tions supporting forward and backward proofs. Based on these proof operations, 
powerful tactics can be defined. We sketched the main user interface aspects 
of the system and described some implementation issues. (Current information 
about Jive can be obtained at www.informatik.fernuni-hagen.de/pi5/jive.html) 
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An Architecture for Interactive Program Provers 



77 



References 



But97. 


B. Buth. An interface between Pamela and PVS. Tech- 


Com79. 


nical report, Universitat Bremen, 1997. Available from 

http: //www . informatik.uni-bremen.de/~bb/bb.html 76 

Computer Science Department, Stanford University. Stanford PASCAL 


COR+95. 


Verifier - User Manual, 1979. 66 

J. Crow, S. Owre, J. Rushby, N. Shankar, and M. Srivas. A Tutorial 
Introduction to PVS, April 1995. 65 


DLNS98. 


D. L. Beliefs, K. R. M. Leino, G. Nelson, and J. B. Saxe. Extended static 
checking. Research Report 159, Digital Systems Research Center, 1998. 
66 


GH93. 


J. V. Guttag and J. J. Horning. Larch: Languages and Tools for For- 
mal Specification. Texts and Monographs in Computer Science. Springer- 


GMP90. 


Verlag, 1993. 64 

D. Guaspari, C. Marceau, and W. Polak. Formal verification of Ada 
programs. IEEE Transactions on Software Engineering, 16(9):1058-1075, 
September 1990. 66 


Gor89. 


M. J. C. Gordon. Mechanizing programming logics in higher order logic. In 
G. Birtwistle and P.A. Subrahmanyam, editors. Current Trends in Hard- 
ware Verification and Automated Theorem Proving. Springer- Verlag, 1989. 
Kopiensammlung. 66 



JvdBH'*’98. B. Jacobs, J. van den Berg, M. Huisman, M. van Berkum, U. Hensel, 



MPH99. 


and H. Tews. Reasoning about Java classes. In Proceedings of Object- 
Oriented Programming Systems, Languages and Applications (OOPSLA), 
1998. Also available as TR CSTR9812, University of Nijmegen. 65 
P. Muller and A. Poetzsch-Heffter. Modular specification and verification 
techniques for object-oriented software components. In G. Leavens and 
M. Sitaraman, editors. Foundations of Component- Based Systems. Cam- 


Owi75. 


bridge University Press, 1999. 65, 68 

S.S. Owicki. Axiomatic proof techniques for parallel programs. Technical 
report, Computer Science Dept., 1975. 72 


Pau94. 


Lawrence C. Paulson. Isabelle: a generic theorem prover, volume 828 of 


PH97a. 


Lecture Notes in Computer Science. Springer- Verlag Inc., New York, NY, 
USA, 1994. 65 

A. Poetzsch-Heffter. Prototyping realistic programming languages based 


PH97b. 


on formal specifications. Acta Informatica, 34:737-772, 1997. 75 
A. Poetzsch-Heffter. Specification and verification of object-oriented pro- 
grams. Habilitation thesis. Technical University of Munich, January 1997. 
65 


PHM99. 


A. Poetzsch-Heffter and P. Muller. A programming logic for sequential 
Java. In D. Swierstra, editor, ESOP ’99, LNCS 1576. Springer- Verlag, 


PQ95. 


1999. 69, 73 

Terence J. Parr and Russell W. Quong. ANTLR: A predicated-LL(k) 
parser generator. Software — Practice and Experience, 25(7):789-810, July 
1995. 75 


Rei95. 


W. Reif. The KIV approach to software verification. In M. Broy and 
S. Jahnichen, editors, KORSO; Methods, Languages, and Tools for the Con- 
struction of Correct Software, volume 1009 of Lecture Notes in Computer 
Science. Springer- Verlag, 1995. 66 



The PROSPER Toolkit* 



Louise A. Dennis^, Graham Collins^, Michael Norrish^, Richard Boulton^, 
Konrad Slind^, Graham Robinson^, Mike Gordon^, and Tom Melham^ 

^ Department of Computing Science, University of Glasgow, G12 8QQ, UK 
^ Computer Laboratory, University of Cambridge, CB2 3QG, UK 
® Division of Informatics, University of Edinburgh, EHl IHN, UK 



Abstract. The Prosper (Proof and Specification Assisted Design En- 
vironments) project advocates the use of toolkits which allow existing 
verification tools to be adapted to a more flexible format so that they 
may be treated as components. A system incorporating such tools be- 
comes another component that can be embedded in an application. 

This paper describes the Prosper Toolkit which enables this. The na- 
ture of communication between components is specified in a language- 
independent way. It is implemented in several common programming 
languages to allow a wide variety of tools to have access to the toolkit. 



1 Introduction 

Modern system design, both for hardware and software, must meet ever- 
increasing demands for dependable products of high quality, with shorter design 
times and early error detection. Incremental improvements to conventional de- 
sign methods and tools are not enough. More powerful techniques of specification 
and analysis based on formal techniques are essential parts of new methods for 
design. 

Formalisms provide specification and analysis at high levels of abstraction, 
so that designers can express and check a wider range of properties than with 
conventional techniques. This permits better structuring of complex systems, 
earlier detection of errors (leading to lower time to market), and higher quality. 

Making effective use of formal techniques does not have to mean doing ‘total 
verification’ against ‘complete formal specifications’ or designing step-by-step 
with a formal refinement theory. This rather modernist Formal Methods pro- 
gramme has still to deliver significant benefits to large-scale design practice, and 
verification has, in consequence, remained largely an academic activity regarded 
sceptically by industry. Instead, one can view formal analysis (or ‘property- 
checking’) of systems as an advanced or more effective form of testing — whose 
objective is not necessarily to have a strong assurance of correctness, but rather 
to eliminate more bugs, earlier in the design process [10]. 

At present, a developer wishing to incorporate verification capabilities into 
a GAD or GASE tool, or any application, will face a difficult choice between 

* Work funded by ESPRIT Framework IV Grant LTR 26241 
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creating a verification engine from scratch and adapting parts of one or more 
existing tools. Developing a verification engine from scratch is time-consuming 
and will usually involve re-implementing existing techniques. Existing tools, on 
the other hand, tend not to be suitable as components that can be patched into 
other programs. Furthermore, a design tool should embed verification in a way 
that is natural to a user, i.e. as an extension to the design process (much like 
debugging is an extension to the coding process). The verification engine must 
be customised to the application. 

The Prosper project^ is addressing this issue by researching and developing 
a toolkit that allows an expert to easily and flexibly assemble proof engines to 
provide embedded formal reasoning support inside applications. The ultimate 
goal is to make the reasoning and proof support invisible to the end-user — or at 
least, more realistically, to incorporate it securely within the interface and style 
of interaction they are already accustomed to. 

This paper describes the Prosper toolkit and the methodology of building 
systems with it. §2 gives a high level view of the toolkit and what a resulting sys- 
tem may look like. While it is inappropriate to give much technical detail here,^ 
§3 tries to give a flavour of the specification for communication. §4 discusses the 
methodology for building systems with the toolkit. §5 presents a case study. §6 
gives an overview of related work. 



2 Design Tools with Custom Proof Engines 

A central part of Prosper’s vision is the idea of a proof engine — a custom built 
verification engine which can be operated by another program through an Ap- 
plication Programming Interface (API). A proof engine can be built by a system 
developer using the toolkit provided by the project. A proof engine is based upon 
the functionality of a theorem prover with additional capabilities provided by 
‘plugins’ formed from existing, off-the-shelf, tools. The toolkit includes a set of 
libraries based on a language-independent specification for communication be- 
tween components of a final system. The theorem prover’s command language is 
treated as a kind of scripting or glue language for managing plugin components 
and orchestrating the proofs. 

The central component is based on a theorem prover because this comes 
with ready made concepts of term, theorem, and goal, which are important for 
managing verifications. A side benefit is that all the functionality in the theorem 
prover (libraries of procedures, tactics, logical theories, etc.) becomes available 
to a developer for inclusion in their custom proof engine. This does not prevent 
theorem proving being very lightweight if desired. 

A toolkit has been implemented based around HOL98, a modern descen- 
dent of the HOT theorem prover [11]. HOL98 is highly modular which suits the 
Prosper approach of building up a proof engine from a set of components (be 

^ http : //www. dcs . gla. ac.uk/prosper 
^ Technical documentation is available from the authors. 
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they HOL libraries or external plugins). It also contains a number of sophisti- 
cated automatic proof procedures. HOL’s command language is ML [19] (a strict 
functional programming language) extended with HOL’s own theorem proving 
functions which extend ML to include the language of higher order logic [6] . This 
allows a developer to have a full programming language available in which to de- 
velop custom verification procedures. Proof procedures programmed in the proof 
engine are offered to client applications in an API. This API can be accessed as 
a verification library in another programming language. 

The toolkit provides several plugin components based on external tools which 
offer APIs to a proof engine. It also provides support to enable developers of other 
verification tools to offer them as Prosper plugins. 

The application, proof engine and plugins act as separate components in the 
final system (Figure 1). In the first prototype they are also separate processes. 




Fig. 1. A system built with the Prosper toolkit 



Communication between them is treated in a uniform manner specified by the 
Prosper Integration Interface. 

Work is currently underway to use this technology to add verification capa- 
bilities to IFAD’s VDM-SL Toolbox [8]. The project is also building a Hardware 
Verification Workbench. This will allow specifications in Verilog and VHDL to 
be checked by a proof engine that incorporates a model checker. 

Example 1. The IFAD VDM-SL Toolbox is a software design tool supporting 
the specification language, VDM-SL. 

The proposed extensions to the Toolbox centre around the discharge of proof 
obligations generated by type invariants. Invariants are undecidable, so the auto- 
matic type checking functionality of IFAD’s toolbox does not check their truth. 

Many invariants can be discharged by first order logic decision procedures. 
To utilise these, the invariant condition needs to be translated from VDM-SL 
into first order logic. In particular, any user-defined functions must be simplified 
away. More complex simplification and theorem proving techniques can be used 
when the conditions fall outside the domain of first order logic. If an automatic 
proof attempt fails then a user must be able to intervene and guide a proof by 
hand. 
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This analysis suggests that the VDM-SL Toolbox requires a first order logic 
plugin; a proof engine with an embedding of the semantics of VDM-SL in higher 
order logic, specialised procedures for simplifying and translating VDM-SL ex- 
pressions into first order logic (a subset of higher order logic) and some more 
complex proof techniques; procedures for the automatic generation of invariant 
proof obligations in the Toolbox itself, and a Toolbox specific interface to the 
proof guidance facilities provided by HOL. These elements can all be constructed 
together into the IFAD Toolbox using the Prosper toolkit. 

3 The Prosper Integration Interface 

A major part of our methodology is the Prosper Integration Interface (PH), a 
language-independent specification of communication for verification. This spec- 
ification is currently implemented in several languages (C, ML, Java and Python) 
allowing components written in these languages to be used together. 

The PII consists of several parts. The first is a datatype, called interface data, 
for all data transferred between an application and a proof engine and between 
a proof engine and its plugins. A major part of the datatype is the language of 
higher order logic used by HOL and so any formula expressible in higher order 
logic can be passed between components. Many plugins operate with logical data 
that is either already a subset of higher order logic (e.g. predicate calculus and 
propositional logic) or embeddable in it (e.g. CTL). The second part consists 
of a datatype for the results of remote function calls and support for installing 
and calling procedures in an API. There are also parts for managing low level 
communication, which are largely invisible to an application developer. 

The PII distinguishes between clients and servers. An application is a client of 
a proof engine which is a client of any plugins it may have. Any server built using 
the toolkit offers an API to clients. This API describes its functionality in terms 
of interface data and a result type (which signals whether a function succeeded 
or failed and returns interface data) . As far as an application or verification tool 
developer is concerned, all components talk the language of these datatypes; The 
details of translating calls made between components into and out of the raw 
communication format are entirely invisible. 

The PII can be viewed as consisting of the layers in Figure 2. The lower layers 
deal with communication (handling interrupts and so on) . The translation layer 
takes the raw data passed along the communication channel and translates it 
into the language’s implementation of interface data. The application support 
layer supplies functions for working with interface data, starting and managing 
communication between components, and support for working with the API. On 
top of this sits the target application, proof engine or plugin. The application 
support layer is the highest specified by the PII. 

3.1 Interface Data 

Interface data is the high level language passed between components of the 
system. It can be used to represent a large number of types and expressions. 
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Fig. 2. The layers of the PII 



The PII gives an abstract specification for interface data, but the exact form of 
the operations and their usage depends on the implementation language. 

Each element of interface data has three operations, a constructor, a destruc- 
tor, and a query (is_a) function which can be used to establish how an expression 
has been constructed. 

Interface data consists of elements based on several standard types (booleans, 
integers, strings, etc.) and lists (allowing tree structures). It also contains special 
elements for handling proof concepts (logical terms, the types of logical terms 
and theorems). 

Logical Terms and Types. Logical terms are central to the Prosper toolkit 
and are not a standard feature of any programming language. Logical terms 
are based on the syntax of classical higher order logic [6] and are the basic 
expressions for communicating logical information (e.g. conjectures that need 
proving). As usual with Church-style formulation, there are four basic elements 
for variables, constants, function applications and lambda abstractions (with 
associated constructor, destructor and query operations). Higher order logic is 
typed so it is also possible to query a term for its logical type. 

These four elements are too low level for everyday use. This is reflected 
in HOL which supplies derived syntax to provide a usable set of constructors 
for common term structures. This approach is also adopted by the interface 
data specification. The interface data derived syntax consists of the usual logical 
connectives and quantifiers plus a few other common constructs. 



3.2 API Support 

The PII application support layer provides functions to allow client and 
server components to handle remote procedure calls. It uses a datatype, 
interface data result, with constructors mk_succeeded: interface_data -> 
interf ace_data_result and mk_failed: interfacejdata -> interface, 

datajresult to report back the results of calls. 
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A client can use the operation, call_server, which calls a function in another 
component’s API, referenced by a string, and supplies it with interface data as 
arguments. It returns an interface data result. 

A server has some database manipulation functions for using an API database 
containing functions of type interf ace_data -> interf ace_datajresult ref- 
erenced by strings. These are used to process calls from a client. 

3.3 Connection Support and Lower Layers 

The PII application support layer includes client side functions for connecting 
to and disconnecting from servers. At present a server has to be started and 
stopped manually, externally to the client. In future we intend to allow servers 
to be started and stopped by the client. 

The low level details of communication handling are only relevant to those 
wishing to implement the PII in various languages. The underlying communica- 
tion is currently based on Internet sockets. 



4 Using the Toolkit 

The basic Prosper toolkit consists of relatively little: a small subset of HOT, 
called the Core Proof Engine. This consists of a theorem type, inference rules 
for higher order logic and an ML implementation of the PII. The Core Proof 
Engine forms the core of all proof engines built using the Prosper Toolkit. A 
developer can write extensions to the Core Proof Engine and place them in an 
API to form a custom API. 

Many applications will require a version of the PII in an implementation lan- 
guage other than ML. The toolkit currently includes PII implementations in sev- 
eral languages and a couple of pre-made plugins (the SMV model checker [17] and 
Prover Technology’s proof tool [23,22]) which can be added into proof engines. 
Third party plugins are already also available for ACL2 [4]^ and Gandalf [25,14]. 

Developing an application using the toolkit is, potentially, a large task involv- 
ing several languages and programs. We have identified three aspects of working 
with the toolkit which separate out the tasks involved. These partition the ef- 
fort into the areas most likely to be undertaken by distinct groups of people. 
The three aspects also help identify which parts of a final system should be 
responsible for which tasks. 



4.1 The Theorem Prover Aspect 

The theorem prover aspect (Figure 3) mainly involves ML programming. This 
programming effort focuses on developing custom procedures and placing them 
in an API which extends the Core Proof Engine. A developer will have access to 
the entire command language of the theorem prover and a set of entrypoints into 

® Currently unpublished, but available at http://www.cl.cam.ac.uk/users/ms204/ 
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as many plugins and theories as they might wish and are available. They will 
be able to develop custom verification procedures and theories within a strongly 
typed, LCF-style, environment. The outcome will be a custom proof engine with 
an API that can be passed on to the developer of an application as a verification 
library. 




Fig. 3. The Theorem Prover Aspect 



On the logical side, a custom proof engine will probably include an embedding 
of the formalism used by the application into higher order logic. It will also in- 
clude automated proof procedures tailored for the application. These procedures 
may well use plugin decision procedures (e.g. for predicate or propositional logic) 
or even include, as plugins, verification tools previously developed as support for 
the application. Construction of such procedures may be a simple process of link- 
ing together highly-developed proof libraries and/or plugins or it may require 
more complex development. 

Although implementations of the PII provide basic functions for calling proof 
engine APIs from clients, any serious application will want to wrap up the API 
with language-specific bindings (e.g. In an object oriented language it would 
be natural to present functions in a proof engine’s API as methods in some 
verification class, thus hiding all instances of call_server from the application 
aspect developer) . This can only be done if the implementation language of the 
target application is known. 



Example 2. In hardware verification there exist many decision procedures for 
verifying designs. Prosper sees its main application here as verification tasks 
that can be handled automatically through combinations of plugin decision pro- 
cedures and theorem proving (see §6). These combined procedures will be devel- 
oped in the theorem prover aspect and presented as the API to a custom proof 
engine. 
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4.2 The Application Aspect 

The application aspect (Figure 4) focuses on the incorporation of a custom 
proof engine into an application so that it appears as a natural extension of 
the application’s functionality. A developer will have access to an API offered 
by a proof engine already customised to their tool. 




Fig. 4. The Application Aspect 



The aim of Prosper is that verification should fit as seamlessly as possible 
into the design flow. We envisage that most of the programming at this stage 
will focus on this task. 

Example 3. The project is investigating the use of a natural language 
interface [13] to the Hardware Verification Workbench that will translate state- 
ments about circuits, in the normal technical language of engineers, into CTL 
propositions that a proof engine can verify. This will allow engineers to be largely 
unaware of the mathematical verification that is taking place. 



4.3 The Plugin Aspect 

The Prosper toolkit supports a third aspect (Figure 5). The developer of a 
verification tool can adapt it so that it can be used as a Prosper plugin. A 
plugin developer programs both in ML and in the plugin’s own implementation 
language. The developer will place chosen entrypoints to the plugin into an API 
database. In the plugin’s implementation language they will translate any ar- 
guments needed by these functions into interface data. In the theorem prover’s 
command language they will need to unpackage these entrypoints again so they 
present themselves as language-specific bindings in that language (ML) . In par- 
ticular any additional theories required (i.e. an embedding of the logic used by 
the plugin into higher order logic) should be provided by the plugin developer. 
The plugin aspect is analogous to the theorem prover aspect except that it is 
assumed that the underlying functionality for the API is already implemented 
and provision of language-specific bindings is strongly recommended since the 
target language is known. 
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Fig. 5. The Plugin Aspect 



It is also possible to run a verification tool in a ‘harness’ provided by the 
Prosper toolkit. This talks to a tool’s command line. This allows almost any 
tool to be used as a plugin, although the tool must be treated as a black box. 



4.4 A Complete System 

An application developer’s view of a complete system should be something like 
Figure 6. Components are accessible to each other via their APIs. Communi- 
cation is made possible by low-level functionality irrelevant to the developer. 
Components can be subdivided into those parts that provide important func- 
tionality, databases of functions in the component’s API, and modules expressing 
the functionality of some other component’s API. 




Fig. 6. A complete system 
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Someone working with such a system can issue an instruction which invokes 
verification. Such an instruction may arise automatically in response to certain 
actions they take in the process of design. This instruction states some conjecture 
which is translated into interface data and passed to a function in the API of the 
proof engine. This function may, by way of example, break the conjecture down 
into a number of sub-problems some of which are dealt with by procedures in the 
proof engine and some of which are passed on as interface data to a function in 
the API of a plugin. The plugin function executes and returns a result. The proof 
engine takes the result and may do some more processing on it before passing 
back its own result to the application. If this is successful and the verification 
arose automatically the user may not even be aware that anything has taken 
place. If it is unsuccessful then the user might receive a warning message about 
the actions they have just performed. 

5 Case Study 

We present a case study of the use of the Prosper toolkit to embed some simple 
verification into a well known, existing application. 

Excel is a spreadsheet package marketed by Microsoft [18]. Its basic con- 
stituents are rows and columns of cells into which either values or formulae may 
be entered. Formulae refer to other cells, which may contain either values or 
further formulae. Users of Excel are likely to have no interest in using or guiding 
mathematical proof, but they do want to know that they have entered formulae 
correctly. They therefore have an interest in ‘sanity checking functions’ that they 
can use to reassure themselves of correctness. 

As a simple case study, the Prosper toolkit developers undertook to incor- 
porate a sanity checking function into Excel. We chose to implement an equality 
checking function which would take two cells containing formulae and attempt 
to determine whether these formulae were equal for all possible values of the 
cells to which they refer. 

Simplifying assumptions were made for the case study. The most important 
were that cell values were only natural numbers or booleans and that only a 
small subset of the functions available in Excel (some simple arithmetical and 
logical functions) appeared in formulae. Given these assumptions, less than 150 
lines of code were needed to produce a prototype. This prototype handled only 
a small range of formulae, but it demonstrated the basic functionality. 

While the resulting program is clearly not marketable (requiring two ma- 
chines using two different operating systems) it was pleasing to find it so easy 
to embed some verification into an existing program. 

5.1 Architecture 

The main difficulty in the case study was that Excel is Windows based, whereas 
the prototype toolkit had been developed for UNIX machines.^ A subsidiary 

^ We intend to port a future version to Windows. 
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difficulty was that the PII was not implemented in Visual Basic, the macro 
language of Excel. 

These problems were solved by using a Python implementation of the PII. 
Python has library support for COM (a middleware component standard which 
is also supported by Visual Basic and is a common way to add functionality 
to Excel). Python also has a freely available socket library, allowing a Python 
program on Windows to communicate via sockets with a proof engine on UNIX. 
The decision was taken not to implement the PII in Visual Basic but to call a 
Python COM server to handle the tasks in the application aspect and commu- 
nicate both as a client to the proof engine running under Linux and as a server 
to an Excel COM client running under Windows. The easiest way to access Ex- 
cel’s formulae is as strings. It would have been necessary, whatever the approach 
taken, to parse these into interface data logical terms and it was unimportant 
whether this effort was made in Visual Basic or in Python. We hope that a 
Python based COM component implementing the PII will be of more general 
interest and use than a Visual Basic implementation of the PII would have been. 
A view of the architecture is shown in Figure 7. 



I 




Windows ' , UNIX 

_____________________ 



Fig. 7. The architecture of Excel with embedded verification 



5.2 The Theorem Prover Aspect 

The initial custom procedure is very simple-minded. It uses an arithmetic de- 
cision procedure provided by HOL98 and a propositional logic plugin decision 
procedure (based on Prover Technology’s proof tool [23,22]) to decide the truth 
of formulae. While the approach is not especially robust, it is strong enough to 
handle many simple formulae. 

This proved to be a very small piece of code (approx. 45 lines of ML were 
needed to write the function and place it in the API database). A more developed 
version of such a proof engine would require longer, more specialised code. 

5.3 The Application Aspect 

A function, ISEQUAL, was written using Excel’s macro editor. Once written, it 
automatically appears in Excel’s function list as a User Defined Function and 
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can be used in a spreadsheet like any other function. ISEQUAL takes two cell 
references as arguments. It recursively extracts the formulae contained in the 
cells as strings (support for this already exists in Excel) and passes them on to 
the Python object. 

The Python component parses the strings to interface data logical terms, 
which it passes on to the decision procedures in the proof engine. It returns the 
result of the proof attempt as true, false, or ‘unable to decide’, which is displayed 
in the cell containing the ISEQUAL formula. 

The application aspect consisted of roughly 30 lines of Visual Basic code and 
30 of Python code. We feel that the case study illustrated the relative speed 
and simplicity with which a prototype of embedded verification can be produced 
using the Prosper toolkit. 

6 Related Work 

Combined Tools. There are many decision procedures available as verification 
tools, especially for use with hardware verification. They all have practical limits 
on the size of design with which they can cope. There has also been a great deal 
of recent work in combining decision procedures (in particular model checkers) 
with automated theorem proving to increase the size of design that can be dealt 
with [1,15,20,21]. The Hardware Verification Workbench, that the Prosper 
project plans to produce, will hopefully make use of much of the knowledge 
and techniques developed for integrating model checkers and theorem proving. 

In a slightly different vein the HOL/CLAM project [3] linked HOL to 
CLAM [5], a proof planning system which specialises in automating inductive 
proof. The HOL/CLAM project is, in some ways, a predecessor to Prosper and 
much has been learned from it. 

All this work has focused on producing one customised solution whereas 
Prosper hopes to provide a framework in which many such interactions can be 
investigated. 

Integration Architeetures. There are several projects that provide a generic 
framework for the integration of tools. 

IOMEGA [2] is a system developed to act as a mathematical assistant. Like 
Prosper, 17mega makes use of other reasoning systems (e.g. resolution theo- 
rem provers and computer algebra systems). These are all incorporated into a 
distributed MathWeb [9] and there is work in progress to produce a standard 
interface for integrating components. 

ETI [24], the Electronic Tool Integration platform, is an ambitious project 
aimed at allowing both the easy and rapid comparison of tools purporting to do 
similar jobs, and also the rapid prototyping of combinations of such tools (any 
software tool, not just verification tools). ETI has its own language, HLL, which 
acts much like Prosper’s combination of ML and interface data to provide 
a scripting language for tool integration. It is also possible to automatically 
generate glue code from easily written specifications. The ETI’s implementation 



90 



Louise A. Dennis et al. 



is based on C++, which allows all tools written in C++ to be treated in a glass 
box fashion, just as Prosper allows all tools written in the languages which 
implement the PII to be treated as glass boxes. 

The OMRS project aims to develop an open architecture for reasoning sys- 
tems to be integrated together relatively easily. This architecture consists of three 
components: the logic of the system [12], the control strategies used by the sys- 
tem [7], and the interaction mechanisms supported by the system. Its framework 
forces systems to identify clearly what are the sequents, inference rules, control 
information, etc. and so makes them more open and extensible. The intention is 
that future reasoning systems will be developed using the OMRS architecture. 
At the same time work is underway to re-engineer popular existing tools, most 
notably ACL2 [4], so that they conform to the OMRS specifications. 

These systems all allow the integration and combination of verification com- 
ponents ranging from an entirely black box treatment to an entirely glass box 
treatment in the case of OMRS. We prefer an easier and more flexible approach 
than OMRS allowing off-the-shelf integration rather than re-engineering. This 
means it is easier to build an unsound tool with our toolkit. We are not ignoring 
the logical issues but intend to solve them on an ad hoc basis. ETI is wider 
in scope but less specific than Prosper. It is forced to treat some components 
as black boxes, which is inappropriate for many of the interactions Prosper 
wishes to study. On the other hand, in many cases it is simple to experiment 
with coordination of several tools using ETI because of its automatic synthesis 
features. 

Design Tools with Embedded Verifieation. The UniForM project aims to en- 
courage the development of reliable software for industrially relevant tasks by 
enabling suitable tool-supported combinations of formal methods. The UniForM 
Workbench [16] is intended to be a generic framework, instantiated with specific 
tools. The project has produced a workbench for software design that gives access 
to the Isabelle theorem prover plus other verification tools through their com- 
mand lines. The various components are held together by Concurrent Haskell, 
which is used as a sophisticated encapsulation and glue language. 

The UniForM project is similar to Prosper, with its focus on the integration 
of component based verification into design tools, its use of a functional language 
to manage the various components, and the provision of a theorem prover to 
perform logical tasks. But, the Workbench is a design tool in its own right rather 
than a toolkit for embedding verification into a design tool. The Workbench also 
treats plugin decision procedures as black boxes. 

We are not aware of any project, other than Prosper, which easily allows the 
integration of existing components with the view to producing an embeddable 
customised proof engine. 

7 Conclusions 

For embedded (possibly invisible) verification engines to gain widespread ac- 
ceptance and use, verification tools must be customisable and combinable. We 



The PROSPER Toolkit 



91 



believe the way forward draws on many of the standard aspects of component 
technology but also requires dedicated support for building custom proof engines, 
such as language-independent datatypes for communicating logical concepts. 

We hope that the work on Prosper has been a significant step forward in 
establishing the nature of the support needed to encourage embedded verifica- 
tion. The focus of future work centres around three areas: basic improvements 
of the underlying implementation; case studies of the effectiveness of the toolkit 
(we are interested not only in the ease with which theorem proving can be em- 
bedded in an application but also in the benefits gained from the combination 
of theorem proving and decision procedures) and the development of generic 
proof support for integrated verification (procedures for handling certain classes 
of plugin effectively, methodologies for ensuring soundness, etc.). 

Most importantly, we believe the way to encourage the incorporation of for- 
mal verification within design flows is not through the provision of some large 
tool that can perform a wide range of verification tasks but through the provision 
of a toolkit that allows the development of specialised proof engines. 
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Abstract. CASL, the common algebraic specification language, has 
been developed as a language that subsumes many previous algebraic 
specification frameworks and also provides tool interoperability. CASL 
is a complex language with a complete formal semantics. It is therefore 
a challenge to build good tools for CASL. In this work, we present and 
discuss the Bremen HOL-CASL system, which provides parsing, static 
checking, conversion to and theorem proving for CASL specifi- 

cations. To make tool construction manageable, we have followed some 
guidelines: re-use of existing tools, interoperability of tools developed at 
different sites, and construction of generic tools that can be used for sev- 
eral languages. We describe the structure of and the experiences with 
our tool and discuss how the guidelines work in practice. 



1 Introduction 

During the past decades a large number of algebraic specification languages 
have been developed. Unfortunately, these languages are based on a diversity 
of basic algebraic specification concepts. The presence of so many similar spec- 
ification languages with no common framework had hindered the dissemination 
and application of research results in algebraic specification. In particular, it 
had made it difficult to produce educational material, to re-use tools and to get 
algebraic methods adopted in industry. Therefore, in 1995, an initiative, CoFU, 
to design a Common Framework for Algebraic Specification and Development 
was started [18]. The goal of CoFI is to get a common agreement in the alge- 
braic specification community about basic concepts, and to provide a family of 
specification languages at different levels, a development methodology and tool 
support. The family of specification languages comprises of a central, common 
language, called CASL^, various restrictions of CASL, and various extensions of 
CASL (e.g. with facilities for particular programming paradigms). 

The definition of CASL and some of its sublanguages has been finished [8]. 
Moreover, a complete formal semantics of CASL [9] has been developed in par- 
allel with design of the language and indeed, the development of the semantics 
has given important feedback to the language design. 

^ CoFI is pronounced like ‘coffee’. 

^ CASL is an acronym for CoFI Algebraic ( or Axiomatic ) Specification Language and 
is pronounced like ‘castle’. 



S. Graf and M. Schwartzbach (Eds.): TACAS/ETAPS 2000, LNCS 1785, pp. 93—108, 2000. 
© Springer-Verlag Berlin Heidelberg 2000 
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Now that design and semantics of CASL have been finished, it is essential 
to have a good tool support. Tools will be essential for the goal of CoFI to get 
CASL accepted in academic communities (in the short run), and, in the long run, 
in industry. This holds even stronger since CASL is a language with a formal 
semantics: many people believe that such a language cannot or will not be used 
in practice: “The best semantics will not win.” [13] 

Since CASL was designed with the goal to subsume many previous frame- 
works, it has become a powerful and quite complex language. This complexity 
makes it harder to build tools covering the whole language. 

In this work, we will show that it is possible to build tools for a complex 
language with strong semantics in a reasonable time. In order to achieve this, 
we have followed several guidelines: 

— As much as possible, re-use existing tools, instead of building new ones. 

— Build tools in such a way that tools developed at different sites can be 
integrated; thus, not every site has to develop all the tools. 

— Make tools as generic as possible. After all, CASL only is the central lan- 
guage in a whole family of languages, and it would be tedious to have to 
re-implement the same things for each language separately. 

All these guidelines are even more important in a non-commercial environment 
as the CoFI initiative is, where only very limited (wo)man-power is available, 
and therefore collaborative effort is essential. Moreover, an explicit goal within 
the design of CASL was to provide a common language in order to achieve a 
better interoperability of (already existing) tools. 

We will discuss these guidelines, reporting how well they work in practice 
and which difficulties arise with them. 

The paper is organized as follows: 

Section 2 gives a brief overview over CASL and its semantics. Section 3 ex- 
plains the general architecture of the Bremen HOL-CASL tool. In section 4, 
tool interoperability using a common interchange format is discussed. Section 5 
describes the problems with parsing CASL’s mixfix syntax. Section 6 recalls 
the encoding of CASL in higher-order logic from [17], while section 7 reports 
our practical experiences when using this encoding to create an interface from 
CASL to Isabelle/HOL. In section 8, some difficulties of encoding CASL struc- 
tured specifications into Isabelle are discussed. Section 9 describes several user 
interfaces for HOL-CASL. Finally, section 10 contains the discussion how the 
guidelines work in practice, and directions for future work. 

This work is based on [17], but considerably extends the work begun there. 

2 CASL 

CASL is a specification language that can be used for formal development and 
verification of software. It covers both the level of requirement specifications, 
which are close to informal requirements, and of design specifications, which are 
close to implemented programs. CASL provides constructs for writing 
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— basic specifications (declarations, definitions, axioms), 

— structured specifications (which are built from smaller specifications in a 

modular way), 

— architectural specifications (prescribing the architecture of an implementa- 
tion), and 

— specification libraries, distributed over the Internet. 

Basic CASL specifications consist of declarations and axioms representing 
theories of a first-order logic in which predicates, total as well as partial functions, 
and subsorts are allowed. Predicate and function symbols may be overloaded [4]. 
Datatype declarations allow to shortly describe the usual datatypes occurring in 
programming languages. 

Structured specifications allow to rename or hide parts of specifications, 
unite, extend and name specifications. Moreover, generic specifications and views 
allow to abstract from particular parts of a specification, which makes the spec- 
ification reusable in different context. 

Architectural specifications allow to talk about implementation units and 
their composition to an implementation of a larger specification (or, vice versa, 
the decomposition of an implementation task into smaller sub-tasks). 

Structured and architectural specifications together with libraries will be also 
referred to as CASL-in-the-large, while basic specifications will be referred to as 
CASL-in-the-small. 

The semantics of CASL follows a natural semantics style and has both rules 
for static semantics (which are implemented by a static semantic checker) and 
model semantics (which are implemented by theorem-proving tools). 



spec List [sort Elem;] — 

free type List[Elem] nil \ __ :: ..{head :? Elem-, tail :? List[Elem]); 
%list [__], nil, .. 

op : List[Elem] x List[Elem] — > List[Elem]; 

%prec __ :: __ < 
vars e : Elem-, 

K, L : List[Elem] 

• %[concat.nil] nil -\--\-L = L 

• %[concat.cons] (e :: K) ++L = e K ++L 
end 

Fig. 1. Specification of lists over an arbitrary element sort in CASL 



Consider the specification of lists over an arbitrary element sort in Fig. 1. 
The free type construct is a concise way to describe inductive datatypes. The 
semantic effect is the introduction of the corresponding constructor (here nil 
and __ :: __) and (partial) selector (here head and tail) functions, and of a num- 
ber of axioms: a so-called sort generation constraint stating that the datatypes 



96 



Till Mossakowski 



are inductively generated by the constructors and possibly by parameter sorts 
(here: the sort Elem), and first-order axioms expressing that the constructors are 
injective and have disjoint images and that the partial selectors are one-sided 
inverses of the corresponding constructors. 

The annotation %list :: __ allows to write lists in the form 

This notation is not restricted to lists: with %list, one also can 
introduce abbreviating notations for sets, bags, etc. 



3 Tool Architecture 



Formatted Casl Text 

t 

LaTEX System 

I 

TEX Code 



Casl Text ■ 

I I 

Parser other parser 

I 

Aterms -4 



t 

LaTEX Formatter 



Static Checker 

I 



Aterms 




Encoding into FOL/FIOL 







other rewriting engine 
other theorem prover 



Transformation System Isabeiie/FIOL Prover 

Fig. 2. Architecture of the HOL-CASL system 



The Bremen HOL-CASL system consists of several parts, which are shown in 
Fig. 2. The parser checks the syntactic correctness of a specification (CASL Text) 
according to the CASL grammar and produces an abstract syntax tree (coded as 
ATerms). The static checker checks the static semantic correctness (according to 
the static semantics) and produces a global environment (also coded as ATerms) 
that associates specification names with specification-specific information such 
as the signature. The formatter allows to pretty print CASL specifications 

(which are input in ASCII format), using the CASL HTeX package from Peter 
Mosses [19]. For example, the specification in Fig. 1 has been generated from 
the ASCII input shown in Fig. 4. 

Finally, the encoding is a bridge from CASL to first- or higher-order logic 
(FOL/HOL). It throws out subsorting and partiality by encoding it [17], and 
thus allows to re-use existing theorem proving tools and term rewriting engines 
for CASL. Typical applications of a theorem prover in the context of CASL are 
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— checking the model-semantic correctness of a specification (according to the 
model semantics) by discharging the proof obligations that have been gen- 
erated during static semantic analysis, 

— validate intended consequences, which can be added to a specification using 
an annotation. This allows a check for consistency with informal require- 
ments, 

— prove correctness of a development step (in a refinement). 



4 Tool Interoperability 

The are quite a number of existing specifications languages and tools for them. 
CASL was designed with the goal of providing a common language for better 
tool interoperability. This is reflected by having a common interchange format 
for CASL tools, the ATerm format [.3] . ATerms are an easy-to-handle format with 
libraries in several languages (C, Java) available. The main reason for chosing 
ATerms was that the untyped term structures are very flexible, and their easy 
syntax makes it very easy to write parsers and printers for them (we needed to 
implement these in our implementation language, ML, which has been done very 
quickly) . 

Thus, ATerms are used as (untyped) low level tool format for data exchange 
between CASL tools. Based on this format, several (strongly typed) formats have 
been designed: the CasFix format [26] for abstract syntax trees, and a format 
for the global environment, containing the static semantic information. 

A problem with ATerms is that the textual representation gets very large 
(the ATerm representation of the global environment for the CASL basic data 
types is about 10 MB). [3] have solved this problem by providing a compact 
binary format with full sharing of subterms. This format can deal efficiently even 
with Gigabyte-sized structures. However, parsers and printers for this format are 
more complex. Thus, we are using converters between the textual and the binary 
ATerm format written in C as a workaround, until an ML-based ATerm library 
dealing also with the binary format becomes available. 

By providing conversions from and to ATerms at all intermediate points in 
the tool architecture, the Bremen HOL-CASL system can be used as a front-end 
or back-end in combination with other tools. Actually, it has been combined as a 
back-end with the Amsterdam CASL parser [27], and as a front-end with several 
theorem proving tools: ELAN [21], PVS [2] and Isabelle (see section 7). See also 
the CoFI Tools Group home page [10]. 



5 Parsing and Static Semantic Analysis 



Apart from having a relatively complex grammar, CASL has several features 
that cause some difficulties for parsing and static analysis: 
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1. CASL’s syntax allows user-defined mixfix syntax, 

2. CASL allows mutually recursive subsort definitions, causing loops within a 
naive subsorting analysis, and 

3. CASL allows overloading, and formulas which have a unique overload reso- 
lution up to semantical equivalence. 

Concerning mixfix syntax, we separate parsing into two steps: The first pass 
of parsing produces an abstract syntax tree where formulas and terms (i.e. those 
parts of the specifications that may contain mixfix symbols) remain in their 
unparsed textual form. 

Mixfix grouping analysis can be done only after a first phase of static seman- 
tic analysis has collected the operation and predicate symbols (among them the 
mixfix symbols). The CASL grammar is then extended dynamically according 
to the mixfix declarations, and formulas and terms are parsed with the generic 
Isabelle parser, which uses the well-known Cocke- Younger-Kasami algorithm for 
context-free recognition [11]. This grammar-parameterised algorithm has a com- 
plexity of O(n^), which is quite acceptable, since formulas and terms in CASL 
specifications are not that long. However, it turned out to be too slow to do the 
first pass of parsing with this approach. Therefore, we moved to ML-yacc for the 
first pass. 

After having done the parsing of terms and formulas, those resulting parse 
trees are selected that are precedence correct with respect to the user-specified 
precedence relations. If more than one parse tree remains, the corresponding 
term or formula is ambiguous, and the possible disambiguations are output to 
the user. To obtain a concise output, not all pretty-printed forms of the parse 
trees are shown, but only the local places at which they actually differ. 

The definition of precedence correctness follows the one of [1], generalized to 
CASL’s pre-order based precedences ([1] uses number based precedences). 

Concerning static semantic analysis, the treatment of subsorts and overload 
resolution needs a careful algorithmic design in order not to run into an expo- 
nential time trap. The details of this have already been worked out in [17]. 

6 Encoding CASL into HOL 

In this section, we briefly recall the encoding from CASL into HOL from [17]: 
At the level of CASL basic specifications, the encoding into higher-order logic 
proceeds in three steps: 

1. The CASL logic, subsorted partial first-order logic with sort generation con- 
straints (SubPCFOL), is translated to subsorted first-order logic with sort 
generation constraints (SubCFOL) by encoding partiality via error elements 
living in a supersort. 

2. Subsorted first-order logic with sort generation constraints (SubCFOL) is 
translated to first-order logic with sort generation constraints (CFOL) by 
encoding subsorting via injections (actually, this is built-in into the CASL 
semantics [4]). 
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3. First-order logic with sort generation constraints (CFOL) is translated to 
higher-order logic (HOL) by expressing sort generation constraints via in- 
duction axioms. 

These encodings are not only translations of syntax, but also have a model- 
theoretic counterpart^, which provides an implicit soundness and completeness 
proof for the re-use of HOL-theorem provers for theorem proving in the CASL 
logic SubPCFOL. This is also known as the “borrowing” technique of Cerioli and 
Meseguer [-5], which allows to borrow theorem provers across different logics. 

7 The Interface to Isabelle/HOL 

Using the encoding described in the previous section, we have built an interface 
from CASL to Isabelle/HOL. We have chosen Isabelle [20] because it has a 
very small core guaranteeing correctness. Furthermore, there is over ten years of 
experience with it (several mathematical textbooks have partially been verified 
with Isabelle). Last but not least, Isabelle is generic, i.e. it supports quite a 
number of logics, and it is possible to define your own logic within Isabelle. 
Despite the genericity of Isabelle, we have refrained from building the CASL logic 
directly into Isabelle - this would violate our guideline to re-use existing tools as 
much as possible: we would have to set up new proof rules, and instantiate the 
Isabelle simplifier (a rewriting engine) and tableau prover from scratch. Instead, 
we re-use the Isabelle logic HOL, for which already sophisticated support is 
available, with the help of the encoding described in section 6. 

This encoding has a clear semantical basis due to the borrowing (most other 
encodings into Isabelle/HOL do not have an explicit model-theoretic counter- 
part). However, a good semantic basis does not imply that there are no practical 
problems: 

First, the encoding of CASL in Isabelle/HOL as described in [17] produces 
too complex output. We had to fine-tune the output by suppressing superfluous 
parts (for example, trivial subsort injections), while retaining its mathematical 
correctness. 

Another problem with borrowing is that the HOL-CASL user really works 
with the encoding of a CASL specification, and not with the CASL specification 
itself. In particular, goals and subgoals are displayed as HOL formulas, and the 
proof rules are of course the Isabelle/HOL proof rules. However, a typical user 
of the tool will probably be more familiar with CASL than with Isabelle/HOL. 
Therefore, we have decided to display goals and subgoals in a CASL-like syntax 
as much as possible. For example, an injection of a term t from a subsort si 
to a supersort s2 is displayed as t : s2, as in CASL, and not as injsi^s 2 {t), as 
the encoding would yield. In this way, we get a CASL-like display syntax of 
Isabelle/HOL. Let us call this display syntax “CASLish Isabelle/HOL”. 

However, note that the CASLish Isabelle/HOL omits some information, e.g. 
the information that an injection injsi,s 2 (t) starts from si. In some practical ex- 
ample proofs, this turned out to be rather confusing (while in others, the longer 



® Formally, they are institution representations in the sense of [16,24] 
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form injsi,s 2 {t) is just tedious), and one would like to go back to the “pure Is- 
abelle/HOL” view of the subgoals instead of using the “CASLish Isabelle/HOL” . 
Therefore, we plan to let the user choose among several pretty printing “views” 
on his or her encoded CAST specification. 

Another example for the mixture of CASL and Isabelle/HOL are Isabelle’s 
two different kinds of free variables, which may occur in CASL formulas during 
a proof. Isabelle one one hand has object variables, which cannot be instantiated 
during a proof. They are used for proofs of universally quantified sentences. The 
other kind of variables are meta variables, which can be instantiated during a 
proof. They are used for proofs of existentially quantified sentences (cf. Prolog, 
narrowing). For example, when trying to prove 

3 X : Nat • a; + 9 = 12 
by elimination of the existential quantifier, one gets 

?a; + 9= 12 

and then lx is instantiated with 3 during the proof (while the goal x + 9 = 12 
would not be provable, since V x : Nat • x + 9 = 12 is false). 



Level 0 

((K ++ L) ++ M) = (K ++ (L ++ M)) 

1. ((K ++ L) ++ M) = (K ++ (L ++ M)) 

Level 1 

((K ++ L) ++ M) = (K ++ (L ++ M)) 

1. ! !xl x2. 

((x2 ++ L) ++ M) = 

(x2 ++ (L ++ M)) =>(((xl :: x2) ++ L) ++ M) = 
((xl : : x2) ++ (L ++ M) ) 

2. ((nil ++ L) ++ M) = (nil ++ (L ++ M) ) 

Level 2 

((K ++ L) ++ M) = (K ++ (L ++ M)) 

No subgoals ! 



Fig. 3. Proof of forall K,L,M:List [Elem] . (K++L)++M=K++(L++M) 



Fig. 3 shows a proof of the associativity of the concatenation of lists, using 
the specification from Fig. 1. Level 0 shows the original goal. In the first proof 
step (level 1), the goal was resolved with the sort generation constraint for lists. 
The two subgoals are the inductive arguments for and nil, respectively. 

In the second step, both subgoals can be proved feeding the axioms concat_nil 
and concat_cons into Isabelle’s simplifier (a rewriting engine). 
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Another problem is that of input of goals. Goals are of course input in 
the CASL syntax (only during a proof, they get redisplayed in CASLish Is- 
abelle/HOL syntax). One would like also to be able to input goals in 
Isabelle/HOL, for example when one needs to prove a lemma that is formu- 
lated in Isabelle/HOL. We solve this by providing Isabelle/HOL as a theory 
within our interface, and we parse goals that are input for this theory always 
with the Isabelle/HOL parser, and not with the CASL parser. 

8 Encoding of CASL Structured Specifications 

The encoding of structured specifications is almost orthogonal to that of basic 
specifications and therefore can be done in a generic, logic-independent way. 

When encoding CASL structured specification into Isabelle, the problem 
arises that the structuring mechanism of CASL and Isabelle are rather different. 
In particular, Isabelle’s mechanisms are considerably weaker: Extensions and 
unions of specifications are available in Isabelle (though the union is defined 
is a slightly different way), while for CASL’s renamings, hidings, and generic 
specifications, nothing similar is available in Isabelle. 

Currently, we solve this problem by just flattening structured specifications 
to basic specifications, that is, we literally carry out all the renamings, unions 
etc. Hidings can be treated by renaming the symbol which shall be hidden with 
a unique name that cannot be input by the user. 

However, this is not very satisfactory, since flattening destroys the structural 
information of a specification and thus makes theorem proving in the specifica- 
tion harder. In some cases, the loss of structural information makes it practically 
infeasible to do proofs which are doable when the structuring is kept. Therefore, 
we have asked the Isabelle implementors to improve Isabelle’s structuring mech- 
anisms, and they have promised to do something in this direction. 

In principle, an alternative way would be to use a deep encoding of CASL, 
which means to directly describe the semantics of CASL within higher-order 
logic. However, this would not be very nice, since theorem proving in a deep 
encoding is relatively far away from proving in the encoded logic. In contrast, 
we use a shallow encoding, where proving in the encoding comes close to proving 
in the encoded logic. The advantage of a deep encoding would be that one can 
prove meta-properties about the semantics of CASL, but in our view, this does 
not outweigh the disadvantages. 

An exceptional case are CASL’s free specifications. One can hardly expect to 
implement them in a logic-independent way, since they depend on an involved 
construction in the model categories of the logic. All that one can expect here 
is to simulate the semantics of free specifications in a particular logic within 
higher-order logic, along the lines of [23]. 

Encoding of architectural specifications is beyond the scope of this paper - 
it will be dealt with elsewhere. 

As described in the previous section, libraries are an orthogonal matter. How- 
ever, there is one important incompatibility between CASL and Isabelle at this 
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You have submitted the CAST library: 



spec List [sort Elem] = 

free type List[Elem] nil | :: (head :? Elem; tail :? List[Elem]) 

%list [ ], nil, 

op ++ : List[Elem] * List[Elem] -> List[Elem] 

%prec :: < ++ 

vars e:Elem; K, L : List [Elem] 

. %[concat_nil] nil ++ L ■ L 
. %[concat_cons] (e::K)++L ■■ e: :K++L 
end 



Result of parsing and static checking: 

Analyzing spec List... 

Parse tree 

lib-defn ( LIB-ID ( indirect-link ( PATH ( "" ) ) ) , LIB-ITEM* ( [ spec-defn ( SIMPLE-ID ( WORDS ( 

"Ust" ) ) , genericlD' ( params ( SPEC* ( [ BASIC-SPEC ( basic-spec ( BASIC-ITEMS* ( [ SIG-ITEMS ( 
sort-items ( SORT-ITEM+ ( [ sort-deci ( SORT+ ([ TOKEN-ID ( TOKEN ( WORDS ( "Elem” ) ) ) { 
empty-display-anno ) 1 )){ label ( ID* ([]))}])))])))])) , imports ( SPEC* ([]))), BASIC-SPEC ( 
basic-spec ( BASIC-ITEMS* ( [free-datatj^e( DATATYPE-DECL+( [datatype-deci (comp-token -id ( _ 

wnpr\Q ( "I i*t” ^ ihj. t \ Tnwpv-in ( Tnir pw r wnpnQ ( "Pia^*" ^ n ^ ^ / L 

Fig. 4. The web interface of the HOL-CASL system 



point: CAST text files may contain libraries consisting of several specifications, 
while Isabelle text files always consist of exactly one Isabelle theory. We solve 
this problem by just splitting a CAST library into small files containing one 
specification each, and feeding these files into Isabelle. Or course, we also have 
to maintain the information associating a CAST library with the split files. 



9 User Interface 



We provide several user interfaces to the Bremen HOL-CASL system. Actually, 
it has turned out that for the first contact with our tool, the most important 
user interface is the web-based interface^, where the user can just type in a spec- 
ification, and parse it, perform the static analysis and/or conversion to HTj;]X. 
Most users want to try out this easy-to-use interface before taking the effort to 
download the stand-alone version (even if the latter effort is very small). The 
web-interface has even been used as a front-end in a prototype translation to 
PVS [2] (although it is much more convenient to use the stand-alone version in 
this case). 



You can play around with it: http://www.informatik.uni-bremen.de/cgi-bin/ 
casl2 . cgi. 



4 



CASL: From Semantics to Tools 



103 



The small stand-alone version of our tool® provides the full functionality 
shown in Fig. 2, except the Isabelle theorem proving environment. It has been 
quite crucial to exclude Isabelle here, since Isabelle is quite large, and users who 
want to use the tool as a front-end or back-end do not want to download the 
whole Isabelle system. The stand-alone tool can be called as a Unix command, 
and the different entry points and phases of analysis and encodings of the tool 
(cf. Fig. 2) can be selected with optional flags. In particular, it is also possible to 
select the encoding into FOL/HOL without having to use Isabelle (this is useful 
when combining our tool with theorem provers for first- or higher-order logic). 
We also plan to make the different steps of the encoding (see section 6) separately 
available, so that one can choose to “encode out” just partiality and keep the 
subsorting (this will be useful, for example, in connection with Maude [6] which 
supports subsorting). The Unix interface works quite well when using the tool 
in combination with other tools, although we plan to provide a fully-fledged 
applications programmer interface (API) in the future. 

The full stand-alone version of the tool® also provides the Isabelle theorem 
prover, and the generic graphical user interface IsaWin [15,14], which has been 
built on top of Isabelle. We have instantiated IsaWin with our HOL-CASL en- 
coding of CASL into Isabelle/HOL. In Fig. 5, you can see a typical IsaWin 
window. The icons labelled with (A, E) are CASL specifications (more precisely, 
their encodings in HOL) . Note that the theory HOL itself also is available at this 
level. The icon labelled with a tree is an open proof goal. By double-clicking on 
it, you can perform proof steps with this goal. This is done by dragging either 
already proven theorems (those icons marked with h A) or simplifier sets (icons 
marked with {I r}) onto the goal. The effect is the resolution of the goal 
with the theorem thrown onto it, or the rewriting of the goal with the chosen 
simplifier set. After the proof of a goal is finished, it turns into a theorem. You 
can then use it in the proof of other theorems, or, if it has the form of a rewrite 
rule, add it to a simplifier set. 

Actually, some users explicitly told us that they feared to have to install 
Isabelle to run our tool. However, even the full version including Isabelle and 
IsaWin is completely stand-alone (apart from the need to install Tcl/Tk, which 
has already been installed on many sites) . 



10 Conclusion and Future Work 

We have shown that it is possible to write tools for a complex language with 
strong semantical bias (though it turns out to be a complex task). We could 
reduce the amount of work by re-using existing tools as much as possible. More- 
over, by using a common tool interchange format, we have created a tool which 
can be used in connection with other tools as a front end or back end. Cur- 

® Available at http://www.informatik.uni-bremen.de/~cofi/CASL/parser/ 
parser.html. 

® Available at http://www.informatik.uni-bremen.de/~cofi/CASL/. 



104 



Till Mossakowski 




Fig. 5. The HOL-CASL instantiation of the IsaWin system 



rently, our tool has been used in connection with two theorem provers (PVS and 
Isabelle) and one rewriting engine (ELAN). 

We have followed three guidelines when implementing the HOL-CASL sys- 
tem. The first guideline was to re-use existing tools, rather than create a new 
tools. In practice, this has turned out to be very hard: Building an interface from 
CASL to an existing tool is quite a complex task, which not only deals with an 
input-output-transformation, but also has to take the interactive behaviour and 
the display of intermediate results into account. 

Nevertheless, we think that it is worth the effort to re-use existing tools, 
since these tools have evolved and improved over time, and in a sense we borrow 
this maturity from other tools, which otherwise would only have been achieved 
through a long process of testing, use and maintenance. Of course, our bridges 
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to other tools also have to become mature, but since the target of the bridging 
tools are already mature, the whole effort can start from a higher level. 

Currently, we have re-used Isabelle/HOL for having a quick prototype of 
theorem proving environment for CASL, at the price to get a very HOLish CASL. 
In future work, we will develop derived rules and tactics for CASL (especially 
for the computation of normal forms w.r.t. the overloading axioms that state 
coincidence of overloaded functions on sub- and supersorts). With this, we will 
try to make the encoding to look more CASL-like by eliminating the need to work 
with HOL rules and instead provide a complete set of rules for CASL. Perhaps 
in a further step, we will even encode CASL directly in the generic Isabelle 
meta logic. Anyway, this step would probably have been too complicated in the 
first place, and working with Isabelle/HOL has the advantage of faster having a 
prototype. 

Concerning the guideline of genericity, we have made the experience that the 
use of generic tools at some points can lead to inefficiencies: we had to replace the 
generic Isabelle parser by ML-yacc to obtain an efficient parsing. Yet, we have to 
use the generic parser for parsing user-defined mixfix syntax. Another experience 
was with the IsaWin system: it has been designed as a generic window-based 
interface to Isabelle, but when instantiating it to HOL-CASL, several changes 
to IsaWin were needed to make it actually useful. Nevertheless, the genericity 
was a great help in comparison to implementation from scratch. 

Regarding genericity of our own tool, we have made the encoding of struc- 
tured specifications independent of the underlying logic. One important future 
point will be to make also the static analysis of CASL structured and archi- 
tectural specifications truly generic, i.e. also parameterized over a logic (this is 
possible because the semantics is already parameterized over a logic) . This would 
allow to re-use the tool also for other logics than the logic underlying CASL (for 
example, higher-order CASL, reactive CASL, temporal logic, or just your own 
favourite logic). 

Concerning interoperability, the use of ATerms helped a lot to interconnect 
our parser and static analysis with several theorem proving and rewriting tools 
at different other sites. Here, it was essential to use the very easy-to-handle 
textual ATerm representation to get quick prototypes of such interconnections, 
although for larger applications, the more complex binary format is needed. 

Another use of the ATerm format will be the comparison of outputs of dif- 
ferent tools for the same purposes that have been developed at different sites. 

We hope that also tools developed by others will be integrated to work with 
our tools in the future. Currently, we have ATerm-based formats for parse trees 
and global static environments. For the integration of different theorem proving 
and rewriting tools, on would also need ATerm-based formats for proofs, proof 
states and possibly also transformations. 

An even better integration can be achieved with the UniForM workbench [12] , 
which also provides library management and access to a generic transformation 
application system [15,14] that will be instantiated to CASL. 
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Future work will turn our tool into a theorem proving environment that can 
be used for practical problems. On the way to this goal, we have to implement 
proof management, dealing with proof obligations, intended consequences and 
refinement. Moreover, special simplifiers and proof tactics for CASL will have to 
be developed an tested. A first case study will be the verification of proof obliga- 
tions and intended consequences for the libraries of CASL basic datatypes [22] . 

Another direction of research will further exploit the possibility of the generic 
analysis of CASL-in-the-large. It is possible to extend CASL to a heterogeneous 
specification language, where one can combine specifications written in several 
different logics, see [25] for some first ideas. Tool support for such a language 
would extend the generic analysis of CASL-in-the-large with an analysis of struc- 
turing mechanisms for moving specifications between different logics. 
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Abstract. We present a method that allows to guarantee liveness by 
construction of a class of timed systems. The method is based on the use 
of a set of structural properties which can be checked locally at low cost. 
We provide sufficient conditions for liveness preservation by parallel com- 
position and priority choice operators. The latter allow to restrict a sys- 
tem’s behavior according to a given priority order on its actions. 

We present several examples illustrating the use of the results, in partic- 
ular for the construction of live controllers. 



1 Introduction 

Building systems which satisfy given specifications is a central problem in sys- 
tems engineering. Standard engineering practice consists in decomposing the 
system to be designed into a set of cooperating components or processes. A 
key problem is the coordination of the components so that the global behav- 
ior satisfies given specifications. Usually, ad hoc design methodologies are used 
leading to solutions that must be validated by verification and testing. In some 
cases, it is possible to solve the coordination problem by synthesizing a controller 
or supervisor that restricts the behavior of the components [3,1]. Both valida- 
tion and synthesis techniques have well-known limitations due to their inherent 
complexity or undecidability, and cannot be applied to complex systems. As an 
alternative to cope with complexity, compositional description techniques have 
been studied. However, the results obtained so far for reactive systems are in 
general difficult to exploit. They boil down either to heuristics of limited appli- 
cation or to general methods formulated as systems of rules with undecidable 
premises. 

Timed systems are models of real-time systems consisting of a discrete con- 
trol structure (automaton) extended with clocks, variables measuring the time 
elapsed since their initialization. At semantic level, they can be considered as 
transition systems that can perform either discrete timeless actions or time steps 
of some real- valued duration. For a timed system to model a real-time system, it 
is necessary that it is timelock-free that is, in any maximal run time diverges. An- 
other essential property for timed systems modeling real-time applications such 
as controllers, schedulers, etc. is that any maximal run contains infinitely many 
actions. We call this property livelock- freedom as it implies deadlock- freedom 
and excludes indefinite waiting. 

We call live a timed system which is both timelock-free and livelock- free. We 
propose a method for building live systems as the composition of live components 
by using parallel composition and priorities. 
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The method is based on a key idea that motivated several papers on the 
compositional description of timed systems [6,7,8]. It consists in enforcing the 
satisfaction of properties by appropriate structural restrictions preserved by 
composition operations. This leads to consider structural properties, intrinsic 
properties of the system which can be checked locally at low cost. We define 
a structural property called structural liveness which implies liveness and can 
be easily checked on components as the conjunction of three more elementary 
structural properties. We combine two kinds of constructs to build structurally 
live systems from structurally live components. 

— Parallel composition operators defined in [6,7,8]. We provide sufficient struc- 
tural liveness preservation conditions for and-synchronization. 

— Priorities allowing to restrict the behavior of a timed system according to a 
given order relation on its actions. We consider timed systems with priority 
orders defined in [6,7,8] and show that priority orders preserve structural 
liveness. This is a basic result used to build live timed systems, as priority 
orders play a central role in our approach. They are used to achieve coordina- 
tion in a system by appropriately restricting the behavior of its components. 
As an illustration of this idea, we show how priority orders can be used to 
specify mutual exclusion constraints by preserving structural liveness. 

The use of the results for the design of live real-time controllers is illustrated 
by several examples. 

The paper is organized as follows. Section 2 presents the properties of liveness 
and structural liveness, as well as sufficient conditions for guaranteeing this prop- 
erty. Section 3 presents priority orders, their properties and results about struc- 
tural liveness preservation when priorities are applied. Section 4 presents com- 
positionality results for systems of communicating processes. Section 5 presents 
a method for the compositional description of mutual exclusion properties by 
using priorities. 

2 Timed Systems and Their Properties 

2.1 Background 

Let A be a set of real- valued variables called clocks. Clocks will be used as 
state variables measuring time progress. Their valuations will be denoted by the 
letter v. true (resp. false) denotes the predicate that is true (resp. false) for 
any valuation v. For any non-negative real t, we represent hy v + t the valuation 
obtained from v by increasing by t the values of all the clocks. 

Definition 1 (Left- and right-closure). A predicate p is called left-closed if 

\/v . ^p{v) => 3e > 0 . Ve' < e . ^p{v e') 

It is called right-closed if it satisfies the previous expression where p{v -\- e') is 
replaced by p{v — e'). 
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Notice that these two definitions correspond to the usual notions if we con- 
sider p as a function of time, where f is a clock valuation. 

Definition 2 (Rising and falling edge). Given a predicate p on clocks X, 
we define the rising edge of p, noted pf by: 

pf{v) = p{v) A 3e > 0 . Ve' G (0, e] . ^p{v — e') V 
~^p{v) A 3e > 0 . Ve' € (0, e] . p{v + e') 

The falling edge of p, noted p[, is defined by the same formula where v — e! and 
V + e' are exchanged. 

Definition 3 (Modal operators). Given a predicate p on real-valued vari- 
ables X, we define the modal operator <>k p ( “eventually p within k”) for k G 
R+ U {oo}. 

P (v) if 3t € R+ 0 <t < k. p{v -\- 1) 

We write Op for Oqo P and Op for ^O^p. 

Notice that the operators are just a notation for existential quantifications 
over time and should not be confused with temporal logic operators. Expressions 
with modal or edge operators can be reduced to predicates on X whenever 
quantification over time can be eliminated e.g., when the operators are applied 
to linear constraints on X . 

2.2 Timed Systems 

Definition 4 (Timed systems). A Timed System is: 

— An untimed labeled transition system (S,^,A) where 

• S is a finite set of control states 

• A is a finite vocabulary of actions 

• S X A X S is an untimed transition relation 

— A finite set X of clocks, real-valued variables defined on the set of non nega- 
tive reals R+. The set of the valuations of X, isomorphic to R” for some n, 
is denoted V . 

— A labeling function h mapping untimed transitions of into timed transi- 
tions.' h{s, a, s') = (s, (a, g, d, /), s'), where 

• g and d are predicates on X called respectively the guard and the deadline 
of the transition. We require that d ^ g. 

• f : V ^ V is a jump. 

According to the above definition, a timed system can be obtained from an 
untimed one by associating with each action a, a timed action b = (a, g, d, /). 

Definition 5 (Semantics of timed systems). A state of a timed system is a 
pair (s,v), where s G S is a control state and v GV. We associate with a timed 
system a transition relation (SxV)x (AuR+) x{SxV). Transitions labeled 
by elements of A are discrete transitions while transitions labeled by non-negative 
reals are time steps. 

Given s G S, if {{s,ai, Si)}i^i is the set of all the untimed transitions issued 
from s and h{s,ai,Si) = {sfiai, gi,di, fi), Si) then: 
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- Vz e / Vi; e R+ . {s,v) ^ {Siji{v)) if gt{v). 

— (s, v) —>■ (s, ?; + t) i/ Vt' < t . Cs(f + t') where Cs = ^ Vig/ di- 

For the state s, we denote by guards and deadlines respectively the predicates 
V.gZ gi and Vig/ di. 

Notice that for time steps we have the following time additivity property. If 
for some t\,t 2 G R+ and some state (s,v), (s,v) + (^ti + ^ 2 )) then 

(s, v) ^ (s,v + ti) ^ (s,v + (ti + 12)), and conversely. Due to this property any 

sequence of time steps can be reduced into a time step of cumulated duration. 
If from some state (s,r') indefinite waiting is allowed, we write (s,v) -^5 (s,oo). 

Timed systems are a variant of TAD [6] with an additional relaxation of 
usual syntactical restrictions ensuring decidability. The simplest timed system 
is a single transition labeled with the timed action (a, g, d, /). The guard g char- 
acterizes the set of states from which the timed transition is possible, while the 
deadline d characterizes the subset of these states where the timed transition is 
enforced by stopping time progress. The relative position of d within g deter- 
mines the urgency of the action. For a given g, the corresponding d may take 
two extreme values: d = g meaning that the action is eager, and d = false, 
meaning that the action is lazy. A particularly interesting case is the one of a 
delayahle action where d = glis the falling edge of a right-closed guard g (cannot 
be disabled without enforcing the action) . The differences between these actions 
are illustrated in fig. 1. 




T — 6 ^ I ^ delayable 

T — X ^ lazy 

Fig. 1. Types for guards 

It has been shown in [7] that any timed system can be described by a bisim- 
ilar system with only eager and lazy timed actions. In practice, we use the 
notation g'^, g^ and g^ to denote a guard g of an action that is respectively eager 
{d = g), delayable {d = gl) and lazy (d = false). 

The containment of deadlines in guards {d g) is necessary for avoiding 
timelocks as it will be explained later. 

Example 1. Consider the timed system of fig. 2 representing a process of period T 
and execution time E. The process has three control states s (sleep), w (wait) 
and e (execute). The clocks t and x are used to impose the period T > 0 and 



On the Construction of Live Timed Systems 



113 



rl 




Fig. 2. A simple process 



the execution time E < T, respectively. The guards {t = T), {t < T — E) and 
{x = E) specify when discrete transitions can occur. According to the type of 
urgency for the actions (denoted by ti, T 2 , and T 3 in the figure), the waiting 
times at control states may change. For instance, if all guards are lazy then it 
is possible for the system to remain stuck forever at one of the states s, w, or e. 
When all guards are eager, discrete transitions are taken as soon as they are 
enabled, which means in particular that the action go is always executed when 
t = 0 (no waiting allowed at w). On the contrary, when go is delayable, this 
action is possible at any time t, 0 < t < T — E. Finally, notice that the behavior 
remains unchanged if eager punctual guards such as x = E are considered as 
delayable. 

Definition 6 (Initial clock valuations). Let s be a eontrol state of a timed 
system and {(si, 6^, s)},g/ with hi = {ai,gi,di, fi) the non-empty set of the in- 
going timed transitions. The set of the initial clock valuations at s is defined as 
the predicate 

iris = \f post{b^) 
iGl 

where post{bi) is the most liberal post- condition of the i-th transition defined by 
post{bi){v) = 3v', g^{v') Av = /*(u') 

When I = $, we take iug to correspond to the valuation where all the clocks are 
set to zero. 



Notice that in most practical cases where guards are linear constraints and 
jumps are linear functions, the quantifier in the expression of post(bi) can be 
eliminated. For the process of fig. 2, in^ = (x = E), in^ = (t = 0) and iue = 
{0 < t < T — E) A {x = 0). 



Definition 7 (Run). A run of a timed system is a maximal sequence of al- 
ternating time steps and discrete transitions starting from (soj'*^o) such that 
ins„{vo). 



(sq,Uo) (sq,Uo + to) ^ (si,Ui) ^ ... (Si,Vi) -A {si,V^ + ti) (Si+i,Uj+i) . . . 



Notice that due to time additivity of the transition system, any execution 
sequence of the model can be represented as a run (where some time steps may 
be of duration zero) . 
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2.3 Structurally Live Timed Systems 

In this section, we study three basic structural properties of timed systems. 
Definition 8 (Timelock- freedom). A timed system is timeloek-free if in any 
run (sq, Wo) ^ {sq, wq + to) ^ (si, w* + U) Yji diverges. 

Definition 9 (Livelock- freedom). A timed system is liveloek-free if in any 
run some action occurs infinitely often. 

Definition 10 (Liveness). A timed system is called live if it is both timeloek- 
free and liveloek-free. 

Definition 11 (Structural non-Zenoness). A timed system is structurally 
non-Zeno if in any circuit of the discrete transition graph at least one clock is 
reset, and it is tested against some positive lower bound. 

Structural non-Zenoness implies that there is a positive lower bound to the 
execution time of any circuit, and is the same as strong non-Zenoness in [16]. 
The periodic process of fig. 2 is structurally non-Zeno since T > 0. 

Definition 12 (Local timelock- freedom). A timed system is called locally 
timeloek-free if for any state s, for any timed transition (a, g, d, f) exiting from s, 
c?t guards . 

Notice that timed systems with left-closed deadlines are locally timeloek- 
free, as ^ d ^ g. Consequently, the timed system of fig. 2 is timeloek-free 
independently of the type of urgency of the actions. 

Lemma 1. At any state (s,w) in a locally timeloek-free timed system, time can 
progress or some action is enabled. (Proof omitted.) 

Lemma 2. Any structurally non-Zeno and locally timeloek-free timed system is 
timeloek-free. (Proof omitted.) 

Definition 13 (Local livelock- freedom). A timed system is called locally 
liveloek-free if for any state s, iug OdeadlinCs, i.e., from any initial state 
some transition will be eventually taken. 

Proposition 1. Any locally timeloek-free and locally liveloek-free timed system 
is liveloek-free. (Proof omitted.) 

Definition 14 (Structural liveness). A timed system is structurally live if it 
is locally timeloek-free, locally liveloek-free, and structurally non-Zeno. 

Clearly, structural liveness is a particular case of liveness that can be char- 
acterized by means of three properties easy to check. 

Example 2. The process of fig. 2 is not locally liveloek-free if one of the actions is 
lazy. Furthermore, even when the actions are delayable or eager, the requirement 
for local livelock- freedom fails for state s, since iug = {x = E), which does not 
imply Oft = T) = {t < T). However, if the guard of rl is strengthened to 
{x = E At < T), the behavior is not modified, and the system is locally liveloek- 
free. So, the system is structurally live for n € {5, e}, i = 1, 2, 3. 
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3 Timed Systems with Priorities 

3.1 Motivation 

In system specification, it is often convenient to consider that some priority is 
applied when from a state several actions are enabled. This amounts to restrict- 
ing the guards of the action of lower priority to leave precedence to actions of 
higher priority. 

Consider for example, two timed transitions (s, (a^, i?i, di, /i), Si), i = 1,2 
with common source state s. If oi has lower priority than 02, then the transition 
labeled by oi becomes (s, {ai,g[, d{, /i), si) with g[ gi and d[ di while the 
other remains unchanged. Commonly, g[ is taken equal to gi A ~^g2 which means 
that when a\ and 02 are simultaneously enabled in the system without priorities 
only 02 is enabled in the prioritized system. However, for timed systems it is 
possible to define priority relations leaving precedence to an action if it is known 
that it will be enabled within some finite time. 

Coming back to the previous example, we can take g{ = gi /\ for some 

finite k, or even g{ = gi /\ ^<>52 ■ In the former case oi gives priority up to 02 
if 02 is eventually enabled within k time units. In the latter case, oi is enabled 
if 02 is disabled forever. 

This motivates a notion of priority within a given delay. As an example, 
consider that gi = 0<x<3\/5<x<8 and 32 = 2 < a; < 7 for some clock x. 
We get the following decreasing values for g[ as the priority delay increases. 




0123456789 

Fig. 3. Different priorities for 02 over oi 



g'i = 9i ^ ^92 = 0<x<2y7<x<8 (immediate priority) 

9i = 9i ^ ~^‘^i 92 = 0 <a;<lV 7 <a ;<8 (priority within a delay of 1 ) 

= 5i A ^<>52 = 7 < X < 8 (priority within an unbounded delay). 

Fig. 3 illustrates the above example. 

The following definition of priority order has been introduced and studied 
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Definition 15 (Priority order). Consider the relation -<C Ax (R+ U {oo}) X 
A. We write a\ 02 for (ai, k, 02) and suppose that \/k € R+ U {00}; 

— is a partial order 

— oi 02 implies \/k' < k. a\ ^k' 02 

— Oi 02 A 02 A/ 03 implies Oi ^k+i 0,3 for all I G R+ U {00} 

Property: The relation oi ^ 02 = oi 02 is a partial order relation. 

Definition 16 (Timed system with priorities). A timed system with pri- 
orities is a timed system TS = (S,^,A,X,h) having all its guards and dead- 
lines left- and right-closed, equipped with a priority function pr. The priority 
function pr associates with each state s G S a priority order pr{s) such that 
if {{oi,9i,di, fi)}i^i is the set of the timed actions labeling transitions issued 
from s, then <>gi <>di for any ai which is not a minimal element ofpr(s). 

A timed system with priorities (TS,pr) represents the timed system TS' = 
{S,^,A,X,h') with the same discrete transition structure and such that if 
h{si,a,S2) = (si, {a,g,d, f),S2) then h'{si,a,S2) = (si, {a, g' ,d' , f), S2) where g' 
is defined in the following manner. 

For a given state s, let -< denote the priority order pr{s), and 
{{oi,gi,di, fi)}i^i he the set of the timed actions labeling transitions ofTS ex- 
iting from s. The corresponding set 0/ prioritized timed actions in TS' is then 
{(oi, 5 ',d',/.W defined by 

9 ^ = A ~^'^k 9 j d'i = d,Ag'i 

tij-e/, fceR+u{oo> 

-<k^j 

This definition simply says that the guard g'^ of a prioritized action ai is not 
enabled if there is some action aj such that Ui Ak aj that will become enabled 
within k time units. 

The requirement Cg <>d for non-minimal actions means that they cannot 
be disabled forever without becoming urgent. It is necessary to avoid overriding 
of deadlines to preserve local livelock- freedom. In fact, the restriction of guards 
(and deadlines) of low priority would violate local livelock-freedom if actions of 
higher priority were lazy. Notice that for typed timed actions, it is sufficient to 
consider priority orders where non-minimal elements are either eager or delayable 
actions. 

We call T S' the prioritized timed system corresponding to (T S, pr) . We de- 
note by guard'g and deadline'^ the restrictions of guards and deadlines in TS' . 

3.2 Preservation of the Structural Properties 

Theorem 1. IfTS satisfies one of the structural properties local timelock-free- 
dom, local livelock-freedom, or structural non-Zenoness, then {TS,pr) satisfies 
the same property. Thus, priority orders preserve structural liveness. 
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Proof. — Local timelock-freedom: priority orders transform a left-closed 
guard g either into left-closed guards g' or into a guard g' such that another 
guard gi of higher priority is true at the rising edge of g' (see definition of 
timed system with priorities). Thus d\ ^ g\/ g\. By induction on the priority 
order it is then possible to show that local timelock-freedom is preserved. 

— Local livelock- freedom: priority orders do not change the discrete transition 
structure of timed systems, and restrict guards of timed actions. Conse- 
quently, for each state s, the set of transitions entering s does not change, 
and iris is restricted. If we note the set of initial clock values of s in the 
prioritized system, and as the non prioritized system is locally livelock-free, 
we have => iris => O deadlines- 

If a deadline d of an action a is restricted to a deadline d' d, then it 
is restricted by some transition (ai, gi, di, /i) such that a o-i, for some 
k G R+U{oo}. This implies dA^d' Okgi Offi. Since ai is not minimal, 
^<?i = Odi. Thus d ^ d' y Odi. It follows that Odeadlines = Odeadline's- 
Thus local livelock-freedom is preserved. 

— Strong non-Zenoness: priority orders do not change the discrete transition 

structure of timed systems, and do not affect jumps. So any circuit in the 
prioritized system is a circuit in the initial one, and the clock resets are the 
same. Moreover, guards are restricted by priority orders, so a lower bound 
in a guard may only increase. Consequently, if the non prioritized system 
is structurally non-Zeno, then the prioritized one is structurally non-Zeno, 
too. ■ 

It is often desirable to restrict a timed system TS with respect to several 
priority functions pr^. At this end, we define a partial operation on priority 
orders. 

Given priority orders on A, we represent by the least priority 

order, if it exists, that contains both and i.e., 

U © ^2 

— if (ai, fci, 02), (02, ^2, C13) then (oi, A:i + /c2, as) 

The partially defined operator © is associative and commutative. We extend © 
on priority functions prp Vs € S.{pri ©pr2)(s) = pri(s) ©pr2(s). 

In order to simplify notations, we extend priority orders to sets of actions: 
<k A^ :<tA Vtti € A^Va2 € A^ .ai -<k »2. 

In the rest of the paper, we show how to build live systems from live compo- 
nents. 

4 Systems of Communicating Processes 

We use the following general framework for the composition of timed systems 
studied in [6,7] and based on the use of an associative and commutative parallel 
composition operator ||. 

Consider timed systems of the form TSi = {Si, Xi,hi). For sake of 

simplicity, we assume that they have disjoint sets of control states Si, disjoint sets 
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of actions Ai^ and disjoint sets of clocks Xi. Furthermore, we consider an action 
vocabulary A, Ai C A, with an operator | such that (A, |) is a commutative semi- 
group with a distinguished absorbing element _L. The action ai|a2 represents the 
action resulting from the synchronization of a\ and 02 (if ai|o2 yf -L). 

Definition 17 (Parallel composition). The parallel composition {TSi,pri)\\ 
(TS2,prs) of two timed systems with priorities {TSi,pri) and (TS2,pr2) is the 
timed system with priorities (TS,pr) defined by 

— TS = {Si X S2 ,A,^,Xi U X 2,h) where if st s' and hi{si,ai, s{) = 
(si, bi, s') with bi = (oi, di, fi), i = 1 , 2 , then 



_L. That is, the transitions of are obtained by interleaving or by syn- 
chronization. 

• If ai |o 2 yf -L, then Ogi = Odi, i = 1,2. 

• h{{si,S2),ai, (s'i,S2)) = ((si,S2),6i, (s'i,S2)) 
h((si,S2),a2, (si,S2)) = ((si,S2),&2, ( 51 , 4 )) 
h((si,S2),ai|a2, (s'i,S2)) = ((si, S2), 61I62, (Sl,52)) 

where 61 [62 is an extension of \ on timed actions, defined later. 

- pr = pri 0 pr2 © pri2, where V(si, S2) G X S'2 . 
pi’i2(si,S2) = {{01,02} ^00 ai|a2 I oi|o2 yf -LA 3 s},S 2 . Si ^ s{ As 2 s'2} 
if pri © pv2 © pr 12 is defined. 

The composition principle is illustrated in fig. 4. Priorities are used to achieve 



maximal progress, that is, interleaving transitions will be taken only when syn- 
chronization is not possible. 

In [6,7] a general method is provided to extend the operator | on timed ac- 
tions, preserving associativity and commutativity. We consider here a particular 
case of timed action synchronization, called and-synchronization, which is de- 
fined as follows: 

For bi = {ai,gi,di,fi),i = 1,2 if ai|a2 yf T, then 61 [62 = (ai |a2, gi A 32, {gi A 
52) A (di V c?2),/i U /2). This simply means that synchronization takes place 
only when both actions are enabled. The synchronization action becomes urgent 





(si.4) W (si.4) 
(s'l.si) 

Fig. 4 . Composition principle 
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whenever it is enabled, and one of the synchronizing actions becomes urgent. 
Finally, /i U/2 denotes the composition of jumps (for disjoint state spaces of the 
components). 

Notice that || is an associative and commutative partial operation on timed 
systems with priorities. We trivially consider a timed system TS as a, timed 
system with priorities (TS^pr^), where pr^ is the priority function associating 
the empty priority order with any state. 

Theorem 2. IfTSi and TS2 are structurally live, then TS\ || TS2 is struc- 
turally live. 

Proof. If (TS,pr) = r5'i||rS'2, then it is sufficient to consider TS” by application 
of Theorem 1, as for synchronizing actions (which are not minimal in pr(s) for 
all s), Ogi = Odi. We show that if TS\ and TS2 are structurally live, then TS 
is structurally live. 

— Structural non-Zenoness: since each transition (interleaving or synchroniza- 
tion) corresponds to a transition in TS\ or TS2 or both, each circuit in the 
product contains a set of transitions forming a circuit in TS\ or TS2. If TS\ 
and TS2 are structurally non-Zeno, then in all these circuits some clock is 
reset and tested against a positive lower bound. Then this is the case for all 
the circuits oiTS too. The bounds of a synchronization action may increase, 
but can not decrease. 

— Local timelock-freedom: conjunction and disjunction preserve closure of 
guards and deadlines, so guards and deadlines of synchronizations are closed 
as well as those of interleaving actions. This guarantees local time-lock free- 
dom. 

— Local livelock-freedom: since interleaving transitions are transitions of the 
components, and synchronization guards are conjunctions of guards of the 
components, if TS\ and TS2 are locally livelock-free we have 

m(si S2) V ius2 => Odeadlinesi V OdeadlinCs2 

=> <> deadline 

Thus, the product system is locally livelock-free. ■ 

Example 3. Consider two structurally live processes P\ and P2 with execution 
times Ei and periods Ti, i = 1,2, running in parallel, as shown in fig. 5. Each pro- 
cess Pi can procrastinate the goi action, which models the start of its execution, 
as long as enough time remains for execution before the end of the period. 

In order to let the processes exchange data, however, one wishes to coordinate 
them by a common go\ \go2 action whenever this is possible without violating 
the timing constraints of any of P± and P2. This is done by synchronizing the 
goi and go2 actions. Maximal progress is ensured in (wi,W2) by the priorities 
goi ^00 goi\go2 and go2 ^00 50i|<?02, and guarantees that the two processes will 
synchronize if they manage to be in (wi,W2) at the same time. The resulting 
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Fig. 5. Two processes with flexible synchronization 

timed actions in the product system with priorities have typed guards g'^, g' 2 , 
and gi 2 , respectively, for goi, go 2 , and goi\go 2 '- 

g[ = ((xi <Ti— El) A -'0(x2 < T2 — F2))'* = ((xi <Ti — Ei) A (x2 > T2 — F2))'* 
52 = ((X2 <T2- E2) A ^ 0 (xi < Ti - Ei)f = {{X2 <T2- E2) A (xi > Ti - Ei))^ 
512 = ((xi < Ti — El) A (x2 <T2 — E2)Y ■ 



The product system is structurally live. 

An important property in the previous example is individual livelock- freedom 
of the components in the product system. Liveness of the product does not imply 
that in any run, an action of some component occurs infinitely often. This remark 
motivates the following definition and theorem. 

Definition 18 (Individual livelock- freedom). A component {TSi,pri) is 
livelock-free in a timed system (TS,pr) = (TSi,pri)\\(TS2,pr2) if in each run 
of{TS,pr), some action of {TSi,pri) occurs infinitely often. 

Theorem 3 . If both {TS\,pri) and (TS2,pr2) are structurally live and each 
synchronizing guard g is hounded (that is, then both TSi and TS2 are 

livelock-free in {TSi,pri)\\{TS2,pr2). (Proof omitted.) 

Example ). Both processes of Example 3 are livelock-free in the product system. 

Remark 1 . Notice that for liveness preservation, the systematic use of “escape” 
actions (aborted communications) in the product system is instrumental. Our 
parallel composition operator allows a process to proceed unsynchronized on 
any action for which the communication will not be ready in its current state 
sometime in the future. This is different from usual “strong” parallel compo- 
sition where synchronization is enforced by the use of restriction operators as 
in CCS [15] or by allowing interleaving only for internal (non communicating) 
actions as in CSP [12]. Such operators enforce synchronization at the risk of 
deadlock, particularly in the case of timed systems. 
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5 Mutual Exclusion 



Consider a timed system initially composed of a set of interacting components. 
The goal is to restrict the behavior of the components by using priorities so 
that the global behavior satisfies a given mutual exclusion constraint. We study 
a method to obtain a structurally live system satisfying mutual exclusion from 
structurally live components. 

The following notion of persistence will be central in this section. 

Definition 19 (Persistence). A control state s is called persistent if in s 
Onguards- 

This property means that at state s, maybe after some waiting, it is always 
possible to execute an action. It is instrumental for avoiding deadlocks when 
guards are restricted by using priorities. 

Consider a timed system (TS,pr) = TS'i|| . . . ||TS'„, where TSi = {Si, 

Xi,hi), and TS = (S,A,^,X,h), as in section 4. We suppose that a mutual 
exclusion constraint is specified as a set M C Si containing pairwise mutually 
exclusive states. We define two predicates on the product space S: 

- badmisi , . . . , s„) = 3i,j,i yf j.Si € M A Sj € M 

- critical M{si,...,Sn) = ~^badM{si, . ■ . , Sm) A 

3a e A, {s[, ...,s'JgS. (si, . . . , s„) A (s(, . . . , s'„) A badM{s [, <). 

badM characterizes all the states violating the mutual exclusion constraint, 
whereas criticalM characterizes all the legal states from which mutual exclu- 
sion can be violated by executing one transition. 

For a given M C S', we define and Mo as the set of actions entering M 
and the set of actions originating in M : 

•M = {a I 3i 3s, s' G S^,s ^ M A s' G M A s ^i s'} 

Mo = {a I 3i 3s, s' G Si, s G M A s -^i s'} 



The set of waiting states of component Si with respect to M is the set of 
states from which some action entering M is issued: {s G Si — M|3a G Ai, s' G 
Si n M s.t. s -^i s'}. 

Theorem 4 (Mutual exclusion). LetTSi . . . ,TSn be a set of structurally live 
timed systems with persistent waiting states w.r.t. a mutual exclusion constraint 
M C IJj S'i, and {TS,pr) = TS'i|| . . . HTS'ji be the parallel composition of the 
components with Voi G »M Va 2 G Al.ai|a 2 = T. Then, the timed system with 
priorities {TS,pr (B pvm), where 



Ws G S . pvm{s) 



•M Aoc Mo if critical m{s) 
0 otherwise 



( 1 ) 



is structurally live, and satisfies the mutual exclusion constraint. 
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Proof (sketch). 

— Structural liveness: Let us first show that {pr(BprM){s) is a partial order for 
all s G S.^badM(s). Suppose that ai ^oo ^2 G pr (i.e., 02 is a synchronizing 
action), and that 02 ^00 G prM- This is not possible, since synchronizing 
actions are maximal in prM- Hence, pr®prM is a priority function. Structural 
liveness follows from Theorems 2 and 1 . 

— Mutual exclusion: No synchronization action can lead (TS,pr (B prj^j) from 
a safe state s G S.^{criticalM{s) V badM(s)) into a badM state violating 
mutual exclusion. 

Let s = (si,...,s„) be a state of TS with criticalM(s), such that there 
exist Sfe, Si, Sk & M and 3 a G Ai.Si s' with s' G M. Thus, a is an action 
leading (TS,pr) into a bad state. Since a G »M, we have ^00 {sfe}o C 
PTm{s). Let us show that from any initial clock valuation of Sfc, some action 
issued from Sfc will eventually be enabled, which means that a is disabled 
due to priority choice semantics. 

From the livelock- freedom assumption about TSk, ing^. deadlines f., one 

can deduce that in the product (TS,pr), for any state satisfying irisj, there 
exists an action in Ag^ = {s^} o U{ai|a2 | a\ G {sfc} o Aa2 G H A ai|a2 yf 
T} with deadline d such that Od. This property remains true as long as 
TSk is in state Sk in {TS,pr). The same argument can be applied for Sk 
in {TS,pr (Bpr^j), as the actions of Ag^. are not restricted by the priority 
function pvM ■ ■ 

Intuitively, equation ( 1 ) says that from critical states, M must be left before a 
new process can enter. The persistence of the waiting states makes sure that no 
process becomes deadlocked while waiting to enter M. 

Remark 2. Notice that the above construction minimally restricts the untimed 
transition structure in the following manner: if from a state s = (si, . . . ,Sn), 
~^badM{s) there exist transitions s ^ s' and s ^ s" with oi G »M and 02 G Mo, 
then critical M (s) , and badM(s'). 

Definition 20 (Individual deadlock- freedom). A component T Si of a timed 
system (TS,pr) = TS'i|| . . . jjTS'n is deadlock-free in TS if for each run of TS, 
some action ofTSi is enabled infinitely often. 

Theorem 5 . Let TSi . . . ,TSn be a set of structurally live timed systems, and 
M Si a mutual exclusion constraint, as in Theorem 4- If for each TSi, o,ny 
run of TSi contains infinitely many occurrences of states in Si~M, the actions 
in Mo do not synchronize, and TSi is livelock-free in (TS,pr) = TS'i|| ... \\TSn, 
then all components are deadlock-free in (TS,pr (B pum)- (Proof omitted.) 

Remark 3. Let TSi he a, structurally live timed system, and M a mutual exclu- 
sion constraint. A sufficient structural condition for the runs of TSi to contain 
infinitely many occurrences of states m Si — M is that the untimed transition 
graph of TSi has no cycles in M. 
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Theorem 6. Let be a set of mutual exclusion constraints on a struc- 

turally live timed system (TS,pr). If pr Mi are the priority functions ensuring 
mutual exclusion according to Theorem 4, and tt = pr (B is a prior- 

ity function, then (TS,tt) is structurally live and respects all mutual exclusion 
constraints Mi. (Proof omitted.) 

Example 5. Consider two processes of periods Ti , T2 and execution times Ei , E2 
as in fig. 6. Each one of the processes is structurally live and remains livelock- 




free in the interleaving product of the two processes, which is structurally live. 
We apply the mutual exclusion constraint M = {ei, 62} on the interleaving prod- 
uct and obtain »M ^00 M°, i-e., {goi,go2} ~<oo {rli,rl2} for the critical states 
(^1,62), (ei,W2). This practically means that release-actions rl have higher pri- 
ority than begin-actions go. According to Theorem 4, the product system with 
priorities is structurally live, and both processes are deadlock- free in it, due to 
the persistent waiting states wi and W2. 

Notice that in order to compute (T5'i|| . . . ||T5'„,pr), it is not necessary to 
compute explicitly the product Ti|| . . . ||T„. Priority choice can be applied “on 
the fiy” to states of the product. 

The construction of Theorem 4 can be generalized for mutual exclusion con- 
straints of the type m-out-of-n for m < n, where critical m{s) (badM{s)) denotes 
the set of control states where exactly m (more than m) components are in M . 

Example 6 (Resource allocation). Consider the well-known example of fig. 7, 
where two interleaving processes Pi and P2 use two shared resources i?i and R2 . 
P\ allocates resource i?i, then i?2, while it still holds i?i, before releasing both 
resources. P2 tries to allocate the resources in the inverse order. 

An action pij means that process Pi allocates resource Rj, and a rii-action 
means that process Pi frees both resources. Mutual exclusion over Ri is modeled 
by the set M\ = {s2, S3, S7}, and mutual exclusion over R2 by M2 = {53,55,57}, 
as indicated by arrows in the figure. Critical states are those characterized by 
criticalMi = (s2 V S3) A 55 V si A 57, and criticalM2 = S3 A 55 V S2 A (55 V 57) 
(where the name of a component state is used as a proposition which is true if 
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Fig. 7. Crossover resource allocations 



the component system is in that state). Mutual exclusion on Mi is guaranteed for 
(TS,prMi), if TS is the interleaving product of Pi and P2- The priority functions 
pi~Mi (i = 1)2) are defined by prMi(s) = »Mi ^oo Mi° for critical Mi(s), 0 
otherwise. We have Vs G 5 : 



prMi (s) 
prM2 (s) 



{Pll,P2l} {P12 ,Vi,V2} 

0 



if critical Ml (s) 
otherwise 



{Pl2,P22} ^oo {P21,Vi,V2} 

0 



if critical M2 (s) 

otherwise 



Both mutual exclusion constraints Mi and M2 are respected by {TS,prMi © 
prMa)) if pi~ Ml ®prM2 is defined. However, in state (s2, se) — Pi has allocated Ri 
and waits for R2, whereas P2 has allocated R2 and waits for Ri — , one can see 
that priorities form a circuit with vertices pi2 and p2i- This flaw in the specifica- 
tion (which means that the specification is intrinsically not deadlock-free) can be 
corrected by declaring states {s2, se} in mutual exclusion. The resulting mutual 
exclusion constraint is M = {s2, S3, se, S7}, which means that the product state 
(s2, sg) is made unreachable. In practice, this means that the sequence consisting 
of the two resource allocations is atomic, and the obtained system is live. 

Notice that each process eventually frees all resources, and the waiting 
states Si and S5 are persistent, so that both processes remain individually 
deadlock-free after composition in this improved specification. 



6 Discussion 

We have presented a method for the construction of live timed systems based 
on the preservation of a set of structural properties by appropriately chosen 
composition operators. Structural properties verification can be done locally and 
does not require exploration of the global system’s dynamic behavior. The set 
of initial states is also structurally determined. 
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An important question to be further investigated is applicability of the 
method. It concerns the expressivity of the class of structurally live systems 
as well as the possibility to apply in practice the liveness preservation theorems. 

We believe that the two properties implying timelock-freedom correspond 
to completely natural common sense requirements of sanity. Structural non- 
Zenoness is a kind of “well-guardedness” property that is satisfied in practice. 
Local livelock-freedom is also a basic property to avoid problems in the inter- 
action between time progress and discrete state changes. The main difficulty in 
the application of our method, is the satisfaction of the local livelock-freedom 
property. It may happen that the initial clock valuation at some state is too 
weak. In that case, the guards of the transitions entering this state must be 
strengthened in an appropriate manner (as in Example 2) and this is left to the 
user’s ingenuity. 

The proposed parallel composition operator can be enhanced by selective 
elimination of escape actions thanks to the use of additional priorities. If all non 
communicating actions are given infinitely higher priority than communicating 
actions then stronger interaction can be achieved and for this parallel composi- 
tion operator Theorem 2 remains true. However, Theorem 3 does not hold and 
it is not easy to find conditions for individual liveness preservation. 

The presented method uses a framework for the compositional description of 
timed systems [6,7,8]. This framework is based on “flexible” composition opera- 
tions in the sense that composition allows only interaction resulting in a global 
behavior that preserves liveness. Priorities are essential for restricting appropri- 
ately the behavior of the cooperating components depending on their abilities to 
synchronize from their respective states. This contrasts with usual composition 
operations which are “constraint oriented” and consider parallel composition es- 
sentially as the intersection of “observable” behaviors. Such operations enforce 
action synchronization and respect components urgency at the risk of livelock or 
timelock. In the presence of timelock or livelock, the behavior of the components 
must be changed to get correct specifications. We prefer flexible composition, 
in spite of its deficiencies, because it is more appropriate for the “correct by 
construction” approach. To our knowledge, this approach has not been very 
much explored so far. [16] defines sufficient static conditions for deadlock- and 
timelock-freedom for the synchronized product of timed automata. Also, there 
exists some work about reactive systems such as [9,13]. 

Concerning the use of priorities, there exist many papers introducing pri- 
orities to process algebras, mainly for the untimed case [5,10,14]. Our notion 
of timed systems with priorities is closer to the work of [14] on the timed pro- 
cess algebra ACSR. However, this work does not tackle problems of property 
preservation. 

This work is part of a more general project which aims at developing tech- 
niques and tools for modeling and analyzing real-time systems. We implemented 
priority choice, parallel composition as well as verification of structural prop- 
erties, in a prototype tool, which we are currently using for the description of 
scheduling algorithms. 
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Abstract. A major problem in model-checking timed systems is the 
huge memory requirement. In this paper, we study the memory-block 
traversal problems of using standard operating systems in exploring the 
state-space of timed automata. We report a case study which demon- 
strates that deallocating memory blocks (i.e. memory-block traversal) 
using standard memory management routines is extremely time-consu- 
ming. The phenomenon is demonstrated in a number of experiments by 
installing the Uppaal tool on Windows95, SunOS 5 and Linux. It seems 
that the problem should be solved by implementing a memory manager 
for the model-checker, which is a troublesome task as it is involved in 
the underlining hardware and operating system. We present an alter- 
native technique that allows the model-checker to control the memory- 
block traversal strategies of the operating systems without implementing 
an independent memory manager. The technique is implemented in the 
Uppaal model-checker. Our experiments demonstrate that it results in 
signihcant improvement on the performance of Uppaal. For example, it 
reduces the memory deallocation time in checking a start-up synchroni- 
sation protocol on Linux from 7 days to about 1 hour. We show that the 
technique can also be applied in speeding up re-traversals of explored 
state-space. 



1 Introduction 

During the past few years, a number of verification tools have been developed for 
real-time systems in the framework of timed automata (e.g. Kronos and Up- 
paal [HH95,DOTY95,LPY97,BLL+98]). One of the major problems in applying 
these tools to industrial-size systems is the huge memory-usage (e.g. [BGK+96]) 
for the exploration of the state-space of a network (or product) of timed au- 
tomata. The main reason is that the model-checkers must store a large num- 
ber of symbolic states each of which contains information not only on the con- 
trol structure of the automata but also the clock values specified by clock con- 
straints. To reduce memory usage, the model-checker must throw away parts of 
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the state-space explored (resulting in memory deallocation), that are not needed 
for further analysis or re-traverse parts of the state-space explored and stored 
in (virtual) memory blocks to check a new property. In both cases, the under- 
ling operating system must traverse the memory blocks storing the state-space 
explored. 

Unfortunately, using the standard memory management service for memory- 
block traversals e.g. memory deallocation is surprisingly time-consuming in par- 
ticular when swapping is involved during state-space exploration. A problem we 
discovered in a very recent case study when Uppaal was applied to check two 
correctness properties of the start-up algorithm for a time division multiple ac- 
cess protocol [LP97]. The first property was verified using 5 hours of CPU time 
and 335MB of memory^ but the memory deallocation process, after verifying 
the first property, did not terminate until 7 days! 

The phenomenon described above is caused by the so-called thrashing, which 
occurs occasionally in common-purpose operating systems, but much more often 
in the context of state-space exploration due to the large memory consumption. 
Unfortunately, this is a phenomenon not only occurring on Linux, but most of the 
existing operating systems. The fact has been demonstrated by our experiments 
on Uppaal installed on Linux, Windows 95 and SunOS 5. Furthermore, we 
notice that as Uppaal is based on the so-called symbolic reachability analysis 
which is the basis for several other model-checkers e.g. Kronos and HyTech, 
this should be a common problem for verification tools in the domain of real-time 
systems. 

More intuitively, the problem can be described as follows: When throwing away 
parts of the state-space, the states are deallocated one by one. Note that the 
size of a state could be a number of bytes. To deallocate the amount of memory 
for a particular state, the memory page containing that state must be in the 
main memory. When swapping is involved, this means that the particular page 
must be loaded from disc. If the next state we want to throw away is in another 
page, and memory is almost full, the newly loaded page must be swapped out, 
even if it needs to be swapped in later when another state shall be removed. If 
the deallocation order is independent of how the allocated states are mapped 
to memory, unnecessary swapping will occur. Therefore, it is crucial to store 
information on the allocation order of memory blocks, but this will introduce 
extra overhead for the model-checker. It is not obvious how much information 
that should be collected during the verification process and used later for deal- 
locating. The more information collected, the more overhead in the verification 
but the better the deallocation performance obtained. We need to find the best 
trade-off. 

As our first experiment, we have simulated the allocation order of memory blocks 
in Uppaal and experimented with three different deallocation orders. The first 

^ The experiment was performed on a 200 MHz Pentium Pro equipped with 256MB 
of primary memory running Red Hat Linux 5. 
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simply traverses the allocated structure without taking into account how blocks 
were allocated. This was the one used in Uppaal when the start-up protocol 
was verified. The second strategy deallocates memory blocks in the same order 
as they were allocated. The third one deallocates them in the reverse allocation 
order. According to our experiments, the last strategy is clearly the best choice, 
which has been implemented in Uppaal. It results in significant performance 
improvements on Uppaal. For example, it reduces the memory deallocation time 
on Linux from 7 days to about 1 hour for the start-up protocol. The technique is 
also implemented to speed up re-traversing of the explored state-space to check 
new properties when the model-checker is used in an interactive manner. Our 
experiments demonstrate similar performance improvement. 

The rest of the paper is organised as follows: In Section 2, we briefly introduce 
the notion of timed automata and symbolic reachability analysis for networks of 
timed automata. In Section 3, we describe and study the memory deallocation 
problem in more details. Several experiments are presented to illustrate that 
it is a common phenomenon for all the common-purpose operation systems. In 
Section 4, we present a solution to the problem and experimental results showing 
that our solution does result in a significant performance improvement for the 
Uppaal tool. Section 5 concludes the paper by summarising our contributions 
and future work. 



2 Preliminaries 

2.1 Timed Automata 

Timed automata was first introduced in [AD90] and has since then established 
itself as a standard model for real-time systems. For the reader not familiar with 
the notion of timed automata we give a short informal description. 

A timed automaton is a standard finite-state automaton extended with a finite 
collection C of real-valued clocks ranged over by x, y etc. A clock constraint is 
a conjunction of atomic constraints of the form: a;~nora; — y~n for x,y £ C, 
{<,<,>} and n being a natural number. We shall use B(C) ranged over 
by g (and later by D) to stand for the set of clock constraints. 

Definition 1. A timed automaton A over docks C is a tuple {N, Iq, E, I) where 
N is a finite set of nodes (control-nodes), Iq is the initial node, E C N x B{C) x 
2^ X N corresponds to the set of edges, and finally, I : N ^ B{C) assigns 
invariants to nodes. In the case, {I, g, r, V) £ E, we write I V . □ 

Formally, we represent the values of clocks as functions (called clock assign- 
ments) from C to the non-negative reals R. We denote by the set of clock 
assignments for C. A semantical state of an automaton A is now a pair (l,u), 
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where I is a node of A and m is a clock assignment for C, and the semantics 
of A is given by a transition system with the following two types of transitions 
(corresponding to delay-transitions and edge-transitions): 

— {I, m)— > {I, u+ d) if I{u) and I{u + d) 

— if there exist g and r such that I V, u G g and 

m' = [r — > 0]u 

where for c? S R, m + c? denotes the time assignment which maps each clock x in 
C to the value u{x) + d, and for r C C, [r 0]u denotes the assignment for C 
which maps each clock in r to the value 0 and agrees with u over C\r. By u G g 
we denote that the clock assignment u satisfies the constraint g (in the obvious 
manner). 

Clearly, the semantics of a timed automaton yields an infinite transition system, 
and is thus not an appropriate basis for decision algorithms. However, efficient 
algorithms may be obtained using a symbolic semantics based on symbolic states 
of the form (I, D), where D G B(C) [HNSY94,YPD94]. The symbolic counterpart 
to the standard semantics is given by the following two (fairly obvious) types of 
symbolic transitions: 



- M{1)Y Mil)^ 

- [l',r{ghD)^ \U ^ V 

where = {u + d\u G D A d G R} and r{D) = {[r — > 0]u | u G D}. It 
may be shown that B{C) (the set of constraint systems) is closed under these 
two operations ensuring that the semantics is well-defined. Moreover, the sym- 
bolic semantics corresponds closely to the standard semantics in the sense that, 
whenever uG D and {l,D) {l\D') then (/,u) ^ ,u') for some u' G D' . 

It should be noticed that the symbolic semantics above is by no means finite 
because clock values are unbounded. However, the following reachability problem 
can be solved in terms of a finite symbolic semantics based on the so-called k- 
normalisation on clock constraints [Pct99,Rok93] . 



2.2 Reachability Analysis 

Given an automaton with initial symbolic state {Iq, Dq), we say that a symbolic 
state {I, D) is reachable if (Iq, D^) (Z„, Dn) and DnAD yf 0. The problem can 

be solved by a standard graph reachability algorithm; but termination may not 
be guaranteed because the number of clock constraints generated may be infinite. 
The standard solution to this problem is by introducing a ^-normalised version 
of the infinite symbolic semantics. The idea is to utilise the maximal constants 



On Memory-Block Traversal Problems in Model-Checking Timed Systems 131 




Fig. 1. An Algorithm for Symbolic Reachability Analysis 



appearing in the clock constraints of the automaton under analysis and D of the 
final symbolic state to develop a finite symbolic transition system. For details 
we refer the reader to [Pet99]. The main fact about the A:-normalisation is as 
follows: 

Assume that k is the maximal constant appearing in an automaton A with 
initial state {Iq,Do). Then (l,D) is reachable from {Iq,Do) iff there exists a 
sequence of ^-normalised transitions: {Iq,Dq) {Li, D'n-i) '^k 

{In, D'^) such that D A D'^ yf 0 where D[ is the so-called normalised constraints 
with all constants being less than k. 

Figure 1 shows the pseudo-code of a reachability algorithm to check if the au- 
tomaton satisfies a given reachability formula e.g. a final symbolic state of the 
form {I, DY . It is basically a standard graph-searching algorithm. The algorithm 
use two important data structures: Waiting and Passed. Waiting contains the 
state-space awaiting to be explored. If this data structure is a queue the search 
order is breath-first; if it is organised as a stack, the search becomes depth-first. 
At start, the initial state is placed in the Waiting structure. Passed contains 
the parts of the state-space explored so far. It is implemented as a hash table 
so that it can be searched and updated efficiently. Initially, it is empty. Due to 
the size of state-space, these structures may consume a huge amount of main 
memory. 



2 



We define that {V , D') |= {I, D) ii V = I and D' A D / 0. 
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Table 1. Memory Deallocation Example 



Memory 


Disc 


Operation 


{s2,s4} 


{sl,s3} 


deallocReq(sl) 

SWAP 


{sl,s3} 

{-,s3} 


{s2,s4} 

{s2,s4} 


dealloc(sl) 


{-,s3} 


{s2,s4} 


deallocReq(s2) 

SWAP 


{s2,s4} 

{-,M} 


{-,s3} 

{-,s3} 


dealloc(s2) 


{-,M} 


{-,s3} 


deallocReq(s3) 

SWAP 


{-,s3} 


{-,s4} 

{-,s4} 


dealloc(s3) 




{-,s4} 


deallocReq(s4) 

SWAP 


{-,M} 




dealloc(s4) 



3 The Problem and Solutions 

The algorithm (or its equivalent) presented in the previous section has been 
implemented in several verification tools e.g. Uppaal for timed systems. Such 
tools are either used in an interactive manner, when the users interactively enters 
reachability properties given as symbolic states, or in a non-interactive manner, 
where the sequence of properties are known a priori. 

When used interactively, the tool may in the worst case construct a huge date 
structure Passed (storing the explored state-space) for each symbolic state when 
it contains a different maximal clock constant. Therefore, before each check, the 
model-checker must traverse and deallocate states (i.e. memory blocks) used for 
previous checks. Note that this is not the only reason why memory deallocation 
is required during the verification process. For example, for each separate reach- 
ability check, parts of the explored state-space may be thrown away when they 
are not needed for further analysis, which also requires memory deallocation. 
In the special case where the whole state-space must be deallocated, and this 
is known before the actual verification starts, it is possible to avoid traversing 
memory blocks by creating a separate process that does the verification. It is 
then possible to deallocate all states just by “killing” the dedicated process and 
have the operating system reclaiming all pages at once. However, this is not 
applicable when only parts of the state-space are deallocated. 

When the tool is used non-interactively, the maximal constant of the whole 
sequence may be determined before the first property is checked, as all symbolic 
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states to be checked are known. Thus, the Passed structure does not have to be 
deallocated between two consecutive checks. In fact, the state-space generated in 
the previous checks is often reused to avoid unnecessary re-computation. A new 
check then amounts to determine if the symbolic state is already in the previously 
generated state-space and, if necessary, continue to generate new symbolic states. 
Note that, independent of how the tool is used, each check requires the previously 
generated state-space to be accessed, either during memory deallocation or when 
reusing the state-space^. Both cases result in memory-block traversals. 

Surprisingly, the time spent on traversing states in Passed consumes a very 
large part of the execution time. The reason is that standard operating-system 
services for memory management requires that the page containing the state to 
access resides in main memory. This is ensured by swapping out other memory 
pages to disc; pages that later may have to be swapped in again because they 
contain other states to access. It is clear that when swapping is involved, it is 
important how the memory is accessed, i.e. in what order the states are accessed. 
Ideally, we would like to localise memory accesses for states as much as possible. 

To improve the presentation, the remainder of this section focuses on techniques 
for more efficient memory deallocation when swapping is involved. However, the 
presented techniques apply also to the case when a large portion of the memory is 
accessed, as when the state-space is reused when several properties are checked. 
We shall study the case of reuse further in the next section. 



3.1 An Example 



To illustrate the problem we study an example where memory is deallocated. 
We assume two memory pages, each containing two states. Initially one page is 
in main memory and one is in a part of the virtual memory currently on disc. 
Tables 2 and 3.1 show the page layout in main memory and on disc together with 
the operations an operating system may perform when the application requests 
deallocation of the states. The strategies illustrated is deallocation of the states 
when they are traversed in an order independent of memory layout and reverse 
allocation order respectively. 

In Table 2 the allocation order is si, s3, s2, s4 and the deallocation order is si, 
s2, s3, s4. SWAP is a very expensive operation and the deallocation strategy 
in Table 2 requires four such operations in order to deallocate all states. In 
Table 3.1 the allocation order is the same as in Table 2 but the deallocation order 
is different; s4, s2, s3, si i.e. reverse allocation order. By using this deallocation 
strategy the number of SWAP operations can be reduced to one. The dealloc() 
can be performed immediately after the request in most cases. 

® In the latter case the search may terminate before the whole state-space has been 
accessed. 
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Table 2. Memory Deallocation Example 



Memory 


Disc 


Operation 


{s2,s4} 

{s2,s4} 

{s2,-} 


{sl,s3} 

{sl,s3} 

{sl,s3} 


deallocReq(s4) 

dealloc(s4) 


{s2,-} 

{s2,-} 


{sl,s3} 

{sl,s3} 

{sl,s3} 


deallocReq(s2) 

dealloc(s2) 


{sl,s3} 

{si,-} 


{sl,s3} 

{-,-} 

{-,-} 


deallocReq(s3) 

SWAP 

dealloc(s3) 


{si,-} 

{si,-} 

{-,-} 


{-,-} 

{-,-} 

{-,-} 


deallocReq(sl) 

dealloc(sl) 



Table 3. Deallocation time (in seconds) for hashtable order 



Blocks 


Linux 


Solaris 


Windows 


32 768 


169 


845 


469 


65 536 


387 


1795 


1038 


131 072 


1029 


4 272 


2 487 


262 144 


2 709 


9 779 


6 250 


524 288 


7 691 


25 193 


12 288 


1 048 576 


27 790 


22 082 


43 227 



3.2 Deallocation Strategies 

A common way to represent state-spaces is to use data structures based on hash 
tables for efficient analysis. A convenient way to deallocate such data structures 
is to go through the table in consecutive hash value order and deallocate the 
symbolic states one by one. This is not by far the most efficient strategy even if 
it is convenient to implement. Table 3.1 shows deallocation times when blocks are 
deallocated in a hash- value order, an order totally ignoring how blocks are layed- 
out on pages and whether requested pages are on disc or in main memory. To 
further emphasise the fact that deallocation order affects the amount of swapping 
see example 3.1. The example in Table 2 and Table 3.1 illustrates the operations 
involved when deallocating memory according to two different strategies. 

A much better strategy would be to first deallocate blocks on pages already in 
main memory and when a page is swapped in from disc deallocate all blocks 
on that page before swapping it out. This strategy would suit most common 
memory-management strategies used in operating systems. However this type of 
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Table 4. Deallocation time (in seconds) for allocation order 



Blocks 


Linux 


Solaris 


Windows 


32 768 


122 


124 


179 


65 536 


124 


125 


193 


131072 


127 


135 


200 


262 144 


128 


151 


240 


524 288 


145 


198 


198 


1 048 576 


176 


242 


300 



low-level information is generally not available to an application program like 
the Uppaal model-checker. Most standard programming languages and portable 
operating system libraries only allow the application programs to request deal- 
location of a previously allocated block. It is up to the application program to 
perform the requests in a suitable order. Information that an application pro- 
gram may maintain is in what order memory blocks have been allocated. 

It is also possible to collect information on how often a memory block is accessed. 
While this may give some hints on whether a block resides on a page in main 
memory or on a page on disc, it is not enough to decide what blocks reside on 
the same page thus leading to the same bad performance with heavy swapping. 

To test if a successful deallocation strategy could be based only on information 
about allocation order, we had an experiment in which 32MB of memory were 
allocated in a number of equally sized blocks on three machines with 32MB of 
physical memory running the operating systems Linux, SunOS 5 and Windows 
95. The blocks were placed randomly in a hash table with place for each allocated 
block. The blocks were then deallocated according to three different strategies: 
We call the first one hash table order. It is used to illustrate a commonly used 
order, easy to implement but independent of memory layout. The second is 
deallocation in the same order as allocation. The third order is deallocation in 
reverse allocation order. 

Table 3.1, 3.2 and 4 show the deallocation times for the three chosen strategies 
implemented on the three operating systems: Linux, SunOS 5 and Windows 95. 
The experimental results clearly indicate that memory deallocation time really 
matters when swapping is involved. Both strategies that utilise the information 
about allocation order are superior to the first one i.e. the table order Note that 
the strategy using reverse allocation order demonstrates the best performance 
on all three operating systems. The reason may be that newly allocated blocks 
are used more recently and hence are more likely to reside in main memory. 



^ Note that this may be the most common strategy adopted by the existing verification 
tools e.g. Uppaal. 
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Table 5. Deallocation time (in seconds) for reverse allocation order 



Blocks 


Linux 


Solaris 


Windows 


32 768 


26 


74 


33 


65 536 


18 


110 


13 


131072 


21 


119 


19 


262 144 


31 


130 


38 


524 288 


44 


153 


44 


1 048 576 


77 


204 


99 



4 Implementation and Performance 

The experimental results presented in the previous section indicate that the 
deallocation strategy currently implemented in Uppaal, which corresponds to 
hash table order, should be modified to optimise the time-performance. Note that 
the problem we want to solve here is how to find a suitable traversal strategy that 
for example let us control memory deallocation efficiently, by localising memory 
accesses as much as possible, without writing our own memory manager. Thus, 
the question is how to keep track of the allocation order of memory blocks 
without getting involved in low-level operations. Certainly, it is not a good idea 
to keep track of the allocation order of all memory blocks, as this might be as 
hard as writing a completely new memory manager. 

Our solution is based on the observation that memory deallocation is mainly 
performed in two different situations: between consecutive reachability checks 
performed on the same system description, and just before the program termi- 
nates. In these situations deallocating memory corresponds to throwing away 
parts of the symbolic state-space that are not needed for the next reachabil- 
ity check. Thus, to utilise the presented deallocation strategies we need to keep 
track of the allocation order of the symbolic states. This is realised by extending 
every symbolic state with two pointers that are used to store the symbolic states 
in a doubly- linked list, sorted in allocation order. The list structure is easy to 
maintain and allows the symbolic state-space to be traversed in allocation order 
and reverse allocation order, as required by the presented memory deallocation 
strategies, in linear time. It also enables deallocation of symbolic states close to 
each other in memory to occur close in time while a page is in main memory, 
i.e. to keep the deallocation as local as possible. 

In fact, the solution is an approximation to the exact allocation order for the 
symbolic states. This is because some operations performed by the reachability 
algorithm change parts of a symbolic state and it cannot be guaranteed that 
all data belonging to a given symbolic state is allocated consecutively. Further, 
all data for a state may not fit together on a single page. These facts make the 
assumption that states allocated consecutively will have all its data collected on 
the same page weaker. 
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4.1 Performance of Deallocation Strategies 

The presented deallocation strategies have been implemented and integrated in 
a new version of Uppaal. In this section we present the results of an experiment 
where the new Uppaal version was installed on Linux, Windows 95 and SunOS 
5, and applied to verify three examples from the literature: 

Bang and Olufsen Audio/ Video Protocol (B&O) This example is a pro- 
tocol developed by Bang and Olufsen that is highly dependent on real- 
time [HSLL97]. It is used in their audio and video equipments to exchange 
control information between components communicating on a single bus. In 
the experiment we have verified the correctness criteria of the protocol. For 
details we refer to section 5.1 of [HSLL97]. 

The verification was performed using Uppaal installed on a Pentium 75MHz 
PC machine equipped with SMB of physical memory running Linux. 
Dacapo start-up Algorithm (Dacapo) The Dacapo protocol is a time divi- 
sion multiple access (TDMA) based bus protocol [LP97]. It is intended for 
physically small safety-critical distributed real-time systems limited to tens 
of meters and less than 40 nodes, e.g. operating in modern vehicles. In the 
experiment we verify that the start-up algorithm of the protocol is correct in 
the sense that the protocol becomes operational within a certain time bound. 
To vary the amount of needed memory in the verifications it is possible to 
adjust the number of communicating nodes of the protocol. 

Four versions of the protocol were verified on four machines: the Pentium 
75MHz described above, a Pentium MMX 150MHz with 32MB of physi- 
cal memory running both Linux and Windows 95, a Pentium Pro 200MHz 
equipped with 256MB of memory running Linux, and a Sun SPARC Station 
4 with 32MB of memory running SunOS 5. 

Fischer’s Mutual Exclusion Protocol (Fischer) This is the well-known Fis- 
cher’s protocol previously studied in many experiments, e.g. [AL92,KLL+97]. 
It is to guarantee mutual exclusion among several processes competing for 
a critical section. In the experiment we verify that the protocol satisfies the 
mutual exclusion property, i.e. that there is never more than one process 
in the critical section. Two versions of the protocol were verified using Up- 
paal installed on the Pentium 75MHz PC. 

Table 4.1 presents the memory usage together with the verification time (check) 
and the time needed to deallocate the required memory (dealloc) in seconds. 
Each example is verified with Uppaal versions deallocating memory using the 
original strategy, i.e. the hash table order, and the two new strategies, namely 
allocation order and reverse allocation order. 

As shown in Table 4.1, memory deallocation in reverse allocation order out- 
performs both hash table order and allocation order in the tested examples. In 
Uppaal, the reverse allocation order saves 82% to 99% of the deallocation time 
compared with the originally used hash table order. It can also be observed that 
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Table 6. Deallocation times (in seconds) 



Memmory Usage 


Machine 


Hash table 


Allocation 


Reverse 


Example 


MB 


OS 


MB 


check 


dealloc 


check 


dealloc 


check 


dealloc 


B&O 


13 


Linux 


8 


1400 


31978 


1486 


1127 


1497 


1067 


Fischer 


8 


Linux 


8 


126 


1 118 


132 


207 


133 


197 




9 


Linux 


8 


135 


1995 


138 


290 


143 


245 


Dacapo 


16 


Linux 


8 


4654 


37 363 


5 031 


8 095 


5 046 


1999 




38 


Linux 


32 


621 


6 013 


689 


812 


690 


597 




38 


Solaris 


32 


3 406 


3 780 


3 740 


304 


3 704 


279 




38 


Windows 


32 


754 


11850 


797 


1035 


823 


995 




56 


Linux 


32 


4413 


164 328 


4 743 


2 781 


4819 


2 647 




56 


Solaris 


32 


8 764 


5 969 


10 271 


384 


10 333 


375 




336 


Linux 


256 


21 189 


602 354 


24 741 


6 754 


23 390 


5 307 



the overhead during verification associated with keeping track of the allocation 
order is relatively small, which varies between 6% and 19% in the experiment. 
Moreover, the space overhead, which is not shown in the table, is insignificant. 



4.2 Performance of State- Space Traversals 



Table 7. Verification times (in seconds) 



1 Memmory Usage 


Hash table 


1 Allocation 


1 Reverse | 


Example 


MB 


check 


re-use 


check 


re-use 


check 


re-use 


Dacapo 


42 


652 


1169 


772 


106 


781 


107 


Fischer 


43 


532 


498 


540 


94 


546 


99 



In section 3 it was mentioned that properties were often verified interactively, 
and that changes in the maximal constants may require deallocation of the whole 
state-space before verification of a new property. If the properties are known a 
priori the maximal constant for all properties can be determined thus eliminating 
the need to destroy the Passed and Waiting structures for that reason. Another 
advantage with such an approach is that we can search through the state-space 
generated so far and check if their already exist states satisfying our reachability 
property and only generate successors of states on Waiting if no states exist in 
Passed. 

This approach would obviously increase the memory consumption and increase 
the possibility of swapping during traversal of the generated state-space since 
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PASSEDand WAiTiNGwill not be deallocated. In fact the same reasoning in find- 
ing a better deallocation order of states may be used here. Assume that we 
want to verify n reachability properties pi...pn. If we traverse the state-space 
in a manner that keeps accesses to states as local as possible we might reduce 
swapping and the verification time for properties p2 to Pn- 

Table 4.2 compares the verification times of traversing the state-space in the 
three different orders described earlier. All of them were implemented in Up- 
PAAL and tested on a 150 MHz Pentium running Linux. To guarantee that the 
same number of symbolic states were search through by all the different strate- 
gies we only verify properties not satisfied by the system. In this way the whole 
generated state-space is traversed in all the three cases. As shown in Table 4.2, 
we obtain reductions in time-usage in traversing the state-space for up to 80%. 

In order to perform experiments involving swapping we have to use examples 
that consume more physical memory than what is available on the given hard- 
ware architecture. Also, we are forced to use existing configurations of processors, 
amount of physical memory and the possibilities to install the different operating 
systems. It turned out that most of our case-studies did not meet the imposed 
requirements. They were either too small or too large. This explains the rich vari- 
ation of used hardware architectures and why the same examples were verified 
multiple times. We still think that the results are significant since the behaviour 
of all three heuristics was consistent for all examples. 



5 Conclusion and Future Work 

We have studied memory-block traversal behaviour of verification tools for real 
time systems. We discovered that deallocating memory blocks during state-space 
exploration using standard memory management routines in the existing operat- 
ing systems is extremely time-consuming when swapping is involved. This com- 
mon phenomenon is demonstrated by experiments on three common-purpose 
operating systems, Windows 95, SunOS 5 and Linux. It seems that the problem 
should be solved by implementing a memory manager for the model-checker. 
However this may be a troublesome task as it is involved in internal details of 
the underlining operating system. 

As the second contribution of this paper, we present a technique that allows the 
model-checker to control how the operating system deallocates memory blocks 
without implementing an independent memory manager. The technique is imple- 
mented in the Uppaal model-checker. Our experiments show that it results in 
significant improvements of the performance of Uppaal. For example, it reduces 
the memory deallocation time on Linux from 7 days to about 1 hour for a start- 
up synchronisation protocol published in the literature. The proposed solution 
introduces very little overhead during the reachability analysis, and it guaran- 
tees that examples not involving swapping still perform well. The technique has 
been applied to speed up re-traversals (i.e. re-use) of the explored state-space in 



140 



Fredrik Larsson et al. 



reachability analysis for timed automata when checking a sequence of properties 
with the same maximal clock constant. 

We should point out that even though most of the experiments presented here fo- 
cus on memory-block deallocation in model-checking timed systems, our results 
are applicable to any problem involving traversals of large amounts of memmory 
in model-checking not only for timed systems, but concurrent systems in general. 
For other work in the context of memory management for automated verification, 
see [Boe93,Wil92,SD98]. As future work, we plan to develop a special-purpose 
memory manager for verification tools, that keeps total control over the alloca- 
tion order and memory layout. 
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Abstract. An important case of hybrid systems are the rectangular au- 
tomata. First, rectangular dynamics can naturally and arbitrarily closely 
approximate more general, nonlinear dynamics. Second, rectangular au- 
tomata are the most general type of hybrid systems for which model 
checking -in particular, Ltl model checking- is decidable. However, on 
one hand, the original proofs of decidability did not suggest practical 
algorithms and, on the other hand, practical symbolic model-checking 
procedures -such as those implemented in HyTech- were not known to 
terminate on rectangular automata. We remedy this unsatisfactory situ- 
ation: we present a symbolic method for Ltl model checking which can 
be performed by HyTech and is guaranteed to terminate on all rect- 
angular automata. We do so by proving that our method for symbolic 
Ltl model checking terminates on an infinite-state transition system if 
the trace-equivalence relation of the system has finite index, which is the 
case for all rectangular automata. 



1 Introduction 

The hybrid automaton [1] is a mathematical model for dynamical systems with 
mixed discrete-continuous dynamics. Model checking has been successfully ap- 
plied to hybrid automaton specifications in automotive [30,32], aerospace [28,29], 
consumer electronics [26], plant control [25], and robotics [11] applications. 

The maximal class of hybrid automata with a decidable model-checking prob- 
lem is the class of rectangular automata^ : in [22] it is shown that linear temporal 
logic (Ltl) requirements can be checked for rectangular automata, while various 
minor generalizations of rectangular automata have formally undecidable reach- 
ability problems. The rectangular-automaton case is of practical significance, as 
hybrid systems with very general dynamics can be locally approximated arbitrar- 
ily closely using rectangular dynamics [20], which has the form x e nr=o[®»’ 

* This research was supported in part by the DARPA (NASA) grant NAG2-1214, the 
DARPA (Wright-Patterson AFB) grant F33615-C-98-3614, the MARCO grant 98- 
DT-660, the ARO MURI grant D A AH-04-96- 1-0341, and the NSF CAREER award 
CCR-9501708. 

^ In this paper, we refer as “rectangular automata” to the initialized rectangular 
automata of [22]. 
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constraining the time derivative x of a state in M” to the n-dimensional rectangle 
^ith rational corner points. The decidability proof of [22], however, 
does not yield a practical Ltl model-checking algorithm (and has never been 
implemented), because it involves a reduction from a rectangular automaton of 
dimension n to a timed automaton of dimension 2n, and dimension (i.e., number 
of clocks) is the most common bottleneck in timed analysis [13]. 

For practical applications, the tool HyTech [19] can be used for checking 
Ltl requirements of rectangular automata. Instead of translating a given rect- 
angular automaton H into a timed automaton, HyTech performs a symbolic 
computation directly on the n-dimensional state space of H . However, the sym- 
bolic procedures employed by HyTech may not terminate, and thus do not 
qualify as decision procedures. In this paper, we resolve the gap between theory 
([22]) and practice (HyTech) by showing how given a rectangular automaton H 
and an Ltl formula (p, we can run a symbolic procedure on the state space of H 
(using the primitives of HyTech) which is guaranteed to terminate and, upon 
termination, returns the states of H that satisfy p. We thus obtain a symbolic 
(rather than reductive) model-checking algorithm (rather than semi-algorithm) 
for Ltl requirements of rectangular automata. 

We obtain our result by first studying symbolic procedures for Ltl model 
checking in a very general setting (Section 2, 3 and 4), namely, for arbitrary 
(infinite-state) transition systems with a computable Pre operator, which given 
a set of states, returns the set of predecessor states. We identify a symbolic Ltl 
model-checking procedure based on the Pre operator, and a structural (syntax- 
independent) condition for transition systems (finite trace equivalence) which 
guarantees termination of the procedure. Since trace equivalence has finite index 
for all rectangular automata [22] , we conclude that symbolic Ltl model-checking 
terminates for rectangular automata. We illustrate our algorithm as applied to 
a rectangular automaton specifying a physical scheduling problem (Section 5). 

Our symbolic Ltl model-checking procedure executes a /r-calculus expres- 
sion which is obtained from a given Ltl formula. It is well-known that Ltl can 
be translated into the /i-calculus [6,12,16], and it has been observed that the 
resulting /r-calculus expressions have a special form [15]: each conjunction has 
at least one argument which is atomic and constant (i.e., contains no fixpoint 
operators or variables). This leads us to define the following procedure, called 
observation refinement (Aor)' starting from a finite initial partition of the state 
space, iteratively compute new sets of states by applying either the Pre operator, 
or intersection with an initial set. We show that Aqr terminates on a transition 
system (i.e., finds only a finite number of sets) if and only if the system has a 
trace-equivalence relation of finite index. Moreover, Aqr termination is a suffi- 
cient condition for termination of the ^-calculus based symbolic model-checking 
algorithm for Ltl. Finally, we show that the /r-calculus based algorithm is, in 
a strong sense, equivalent to the standard, product-automaton based algorithm 
for symbolic Ltl model checking [9]. 

Thus, Aor plays with respect to Ltl a role that is similar to the role of 
partition refinement {Apr), which iterates Pre, (unrestricted) intersection, and 
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set difference, with respect to branching-time logics: the termination of Apr on & 
transition system guarantees that symbolic model checking for the full ^-calculus 
(or Ctl, Ctl*) also terminates. This is because Apr computes the bisimilarity 
quotient [27]. While Apr is known to terminate on timed automata [2], whose 
time-abstract bisimilarity quotients are finite, there are rectangular automata 
on which Apr does not terminate [17]. However, since rectangular automata 
have finite trace-equivalence quotients, Aqr terminates on every rectangular 
automaton, thus enabling symbolic Ltl model checking. 

2 Symbolic Model Checking for Infinite-State Systems 

2.1 Transition Structures 

A transition structure 1C = (Q, iT, ((•)), i5) consists of a (possibly infinite) set Q of 
states, a finite set II of observables, an observation function ((•)): Q ^ 2^ which 
maps each state to a set of observables, and a transition function 6: Q ^ 2^ 
which maps each state to a nonempty set of possible successor states. We say 
that an observable tt holds at a state q if tt S {{q)) . A state g is a successor of a 
state p if q € S{p). A source-qo run of 1C is an infinite sequence r = go<Zi 92 ... of 
states such that is a successor of qi for all i > 0. The run r induces a trace, 
denoted ((r)), which is the infinite sequence ((go)) ((9i)) (( 92 )) ... of observable sets. 
For a state q G Q, the outcome from g is the set of all runs of 1C with source g. 
For a set L of runs, we write ((L)) for the set {((r)) j r S L} of corresponding 
traces. 

A binary relation A* C Q x Q is a trace containment if p q implies 
{{L^)) C {{L^))- Define p q if there exists a trace containment with p A* g. 
Define the trace-equivalence relation as p q if both p q and g d^ P- A 
binary relation A® C Q x Q is a simulation ifpd^q implies (1) ((p)) = ((g)), and 
(2) for all states p' G S{p), there exists a state g' G 6{q) such that p' A® g'. A 
binary relation on Q is a bisimulation if is a symmetric simulation. Define 
p q if there is a bisimulation with p g. The equivalence relation is 
called bisimilarity. 

The observables induce an equivalence relation called atomic equiva- 
lence, on the states Q, with p g iff ((p)) = ((g)). The equivalence classes of 
are called atomic regions. Let A denote the set of atomic regions. For an equiva- 
lence = on the states Q which refines =^, define IC/-^ = {Q/^, II, {{-))9i,5^), the 
quotient structure of 1C with respect to =, as follows. The states in the 

equivalence classes of =. The observables are the same as those of /C. Define the 
observation function ((-))s as tt G ((7?))s if tt G ((g)) for any/all states g G i?. 
Define the transition function as i? G Ssi{P) if there are a state p G P and a 
state q G R such that g G 5{p). 

2.2 Symbolic Semi-algorithms 

Let /C be a transition structure. A region is a (possibly infinite) set of states 
of JC. If the state space of 1C is infinite, any algorithm that traverses the state 
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space must represent regions implicitly, as formulas in some constraint system. 
With a transition structure 1C we associate a symbolic theory [23], which consists 
of (1) a set S of region representatives containing finite representations of some 
regions of /C, and (2) an extension function : 27 — > 2*^ which maps each region 
representative to the region it represents, such that the following conditions are 
satisfied: 

— For every atomic region R G A, there is a region representative € 27 

such that = R. Let 27^ = {an \ R G A} denote the set of region 

representatives for the atomic regions. 

— For every region representative ct C 27, there is a region representative 
Pre{a) G 27 such that Pre{a)~' = {q C Q \ S{q)r]'~a~' yf 0}; furthermore, the 
function Pre: E ^ S can be computed algorithmically. 

— For every pair of region representatives <t, r G 27, there are region represen- 
tatives And{a,T), DijJ{a,r) G 27 such that ’~And{a,r)~' = '“ct"' n '"r"' and 

Diff{a,T)~' = \ furthermore, the functions And,Diff: E x E —f E 

can be computed algorithmically. 

— The emptiness of a region representative is decidable; that is, there is a 
computable function Empty: 27 ^ B such that Empty{a) iff '~cr~' = 0. 

— The membership problem for a state and a region representative is decidable; 
that is, given a state q and a region representative a, it can be decided if 
q G 

A symbolic semi-algorithm takes as input the symbolic theory for a transition 
structure /C, and generates region representatives in 27 by applying the operations 
Pre, And, Diff, and Empty to the atomic region representatives in Ea- The 
expression “semi-algorithm” indicates that, while each operation is computable, 
the iteration of operations may or may not terminate. Two examples of symbolic 
semi-algorithms are well-known. The first is backward reachability, denoted Ao- 
Given an atomic region representative a G Ea, the symbolic semi-algorithm Ao 
starts from ag = a and computes inductively the region representatives di+i = 
Pre(ai). The semi-algorithm terminates if there is a A: such that — 

that is, no new state is encountered. Termination can be detected 
using the operations Diff and Empty [23]. Upon termination, a state q can reach 
the atomic region '"a”' iff q G for some 1 < i < fc. 

The second example is partition refinement [7,27], denoted Apr. The sym- 
bolic semi-algorithm Apr starts from the finite set Sg = Ea of atomic region 
representatives and computes inductively the finite sets 

= SiU{Pre{a),And{a,T),Diff{a,T)\a,TGSi} 

of region representatives. The semi-algorithm terminates if there is a fc such that 
1 a G 5fe+i} C ffa~' \ a G Sk}; that is, no new region is encountered. 
Termination can be detected using the operations Diff and Empty: for each 
region representative a G Sk+i check that there is a region representative t € Sk 
such that both Empty (Diff (a, t)) and Empty (Diff (t, a)). Upon termination, 
two states p and q are bisimilar iff for all region representatives cr G 5fc, we have 
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p G iff g G Thus, the symbolic semi-algorithm Ap/{ terminates iff the 
bisimilarity relation ='® has finite index [18], as is the case, for instance, for 
timed automata [2]. 

2.3 Symbolic Model Checking 

A state logic £ is a logic whose formulas are interpreted over the states of tran- 
sition structures. For a formula p oi L and a transition structure /C, let |</3 ]k: be 
the set of states of /C that satisfy p. The £ model- checking problem asks, given 
an £-formula p, a transition structure 1C, and a state q of 1C, whether q G 
A logic £ induces an equivalence relation ='^ on states: for all states p and q of 
a transition structure 1C, define p q if for all £- formulas p, we have p G 
iff <7 S Thus, two states p and q of a transition structure JC are equivalent 

with respect to iff there is no formula in the logic £ that can distinguish p 
from q. Two formulas p and if) of state logics are equivalent if = K 

for all transition structures JC. The logic £i is as expressive as the logic £2 if 
for every formula '0 of £ 2 , there exists a formula p of £1 equivalent to tp. The 
logics £1 and £2 are equally expressive if £1 is as expressive as £ 2 , and £2 is as 
expressive as £ 1 . 

A state logic £ admits abstraction if for every equivalence relation = that 
refines =^, for every £- formula p, and for every transition structure 1C, the 
region |(/3 ]k: is UMk/-- ^ admits abstraction, and = refines =^, then = is 
called an abstract semantics for £; if £ admits abstraction, then is the fully 
abstract semantics for £. Let £ be a logic that admits abstraction, and let = 
be an abstract semantics for £. Then a state p of 1C satisfies an £-formula p iff 
the =-equivalence class containing p satisfies tp in the quotient structure JC/si- 
This means that instead of model checking the structure JC, we can model check 
the quotient structure JC/si- In case the equivalence relation = has finite index, 
we can so reduce model-checking questions over an infinite-state structure to 
model-checking questions over a finite-state structure. 

A simple state logic of interest is the logic Efl, which contains all formulas 
of the form 30<p, where is a boolean combination of observables. The formula 
3C>ip holds at a state g of a transition structure JC if there exists a source- 
q run r of JC, and a state p in r, such that ip holds in p. A model-checking 
algorithm for the logic Efl is easily derived from the symbolic semi-algorithm 
Ao (backward reachability). In particular, if Ao terminates on every atomic 
region representative of 1C, then Efl model checking can be decided over JC. 
The logic Efl can express reachability (or dually, safety) properties. To express 
more interesting properties, we define the fi-calculus, which can encode temporal 
logics such as Ltl, Ctl, and Ctl* [14]. The formulas of the /r-calculus are given 
by the grammar 

ip ::= TT \ ^TT \ X \ ipiC ip2 \ <P1 f\<P2 \ 30 £ I VQ £ I pX. ip \ vX. ip, 

where tt is an observable, A is a propositional variable, p is the least-fixpoint 
operator, and v is the greatest-fixpoint operator. We interpret closed formulas 
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over states in the standard way [14]. For example, the Efl formula BOtt is 
equivalent to the /i-calculus formula fiX.{Tr V 3Q -^)- 

The /i-calculus admits abstraction, and bisimilarity is a fully abstract 
semantics for the /i-calculus. Thus, if an infinite-state transition structure JC 
with a symbolic theory has a finite bisimilarity quotient ICj or equivalently, if 
the symbolic semi-algorithm Apr (partition refinement) terminates on /C, then 
/i-calculus model checking can be decided over /C: first, use partition refinement 
to compute the finite-state structure /C/as; then, model check over /C/^b. There 
is, however, also a more direct, more efficient way of /i-calculus model checking 
over infinite-state transition structures with symbolic theories: we can attempt 
to compute fixpoints by successive approximation [8], using the operations Pre, 
And^ and Diff [18]. If the successive approximation of each fixpoint subformula 
of a /i-calculus formula ip terminates in a finite number of steps, then we arrive at 
the region in a finite number of applications of Pre, And, and Diff . Clearly, 
a sufficient condition is the termination of Apr, which applies all possible com- 
binations of the three operations. The symbolic semi-algorithm for /r-calculus 
model checking, which performs only the subset of operations of Apr called for 
by the input formula, is denoted Afj,. For example, for the Efl formula BOtt, the 
semi-algorithm A^ is identical to ^o- 

3 A Symbolic Characterization of Trace Equivalence 

3.1 Observation Refinement 

We define a symbolic semi-algorithm, called observation refinement and de- 
noted Aor, which repeatedly applies the two operations Pre and intersection 
with atomic region representatives, until no new regions can be generated. The 
symbolic semi-algorithm Aqr starts from the finite set Sq = Da of atomic region 
representatives and computes inductively the finite sets 

iSi+i = Si U {Pre{a), And{a,r) | <t S and r G Ea} 

of region representatives. Note that only a restricted form of intersection (inter- 
section with atomic regions) is allowed. The semi-algorithm terminates if there 
is a fc such that {'“cr"' | a G 5fe+i} C {'“cr"' | a G Sk}; this is checked as in the 
case of Apr (partition refinement). Observation refinement will typically pro- 
duce more region representatives than Ao (backward reachability), but fewer 
than Apr. In particular, there are infinite-state transition structures on which 
backward reachability terminates, but not observation refinement; and structures 
on which observation refinement terminates, but not partition refinement. 

3.2 The Guarded Fragment of the /r-Calculus 

For a logical characterization of the regions computed by observation refinement, 
we define G/r, the guarded fragment of the ^.-calculus, as the set of formulas given 
by the following rules: 
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1. All observables and propositional variables are formulas of G^. 

2. If 7T is an observable, then ^tt is a formula of G/r. 

3. If and tp 2 are formulas of G/i, then 

(a) Lpi V (/32, 3Q (fi, and vX. ipi are formulas of G/i. 

(b) A (/?2 is a formula of G/i provided at least one of tpi and (p 2 is a boolean 
combination of observables. 

This definition is similar to the definition of Li in [-5,15].^ Over finite-state tran- 
sition structures, there is a fast, 0{mnk) model-checking algorithm for G/i, 
where m is the size of the transition structure, n is the size of the formula, 
and k is the alternation depth of the formula [5] . 

Proposition 1. The guarded fragment of the fi-calculus admits abstraction. 

The equivalence relation induced by the guarded fragment of the /i-calculus 
is characterized operationally by observation refinement. By induction, each re- 
gion computed in step i of the symbolic semi-algorithm Aqr is a block (i.e., a 
union of equivalence classes) of Thus, if has finite index, then Aqr 
terminates. Conversely, suppose that Aqr terminates with = Sk- We can 
show that if two states are distinguished by a formula in G/r, then there is a 
region constructed by Aqr that separates them. Define the state equivalence 
as p (/iff for each region representative a G Sk, we have p G iff 
q G ’"cr”'. It follows that p q implies p q. 

Proposition 2. Observation refinement (Aqr) terminates on the symbolic the- 
ory of a transition structure K. iff the equivalence relation induced by the 
guarded fragment of the p-calculus on K. has finite index. 



3.3 Expressiveness of the Guarded Fragment 

We can alternatively characterize the expressiveness of G/i using a linear-time 
logic (without path quantifiers). A Biichi automaton S is a tuple {S, <T, sq, F), 
where S' is a finite set of states, <P is a, finite input alphabet, — > C S x x S 
is the transition relation, sq G S is the start state, and F C S is the set of 
Biichi accepting states. An execution of B on an w-word w = wawi . . . G is 
an infinite sequence r = sqSi ... of states in S, starting from the initial state sq, 
such that for all i > 0. The execution r is accepting if some state 

in F occurs infinitely often in r. The automaton B accepts the word w if it has 
an accepting execution on w. The language L(B) C is the set of w-words 
accepted by B. 

Let Ebl be the state logic whose formulas have the form 3B, where B is a. 
Biichi automaton whose input alphabet are sets of observables; that is, <P = 2^ . 

^ In [15], condition (2) of our definition is changed to “If ip is an Li formula that does 
not contain any variables, then -^^p is in Li,” and condition (3b) is changed to “If pi 
and p 2 are Li formulas such that at most one of them contains any variables, then 
pi A p 2 is in Li.” It can be shown that Li and G/r are equally expressive. 
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The formula holds at a state g of a transition structure 1C if there exists 

a source-g run r of /C such that ((r)) S L{B). The logic Ebl admits abstraction, 
and trace equivalence is a fully abstract semantics for Ebl. Now we show that 
Ebl is as expressive as the guarded fragment of the /r-calculus. This result is 
implicit in a proof in [15], although it is never explicitly stated. 

Lemma 1. Given a formula ip (over the observables II), we ean eonstruct 
a Biichi automaton (on the alphabet 2^ ) sueh that = pjyc for all 

transition structures 1C. Conversely, given an Ebl formula 3B (over the alpha- 
bet 2^), we can construct an Gp formula ips (over the observables II) so that 
= P;B]k; for all transition structures 1C. 

The proof of the first part of the lemma proceeds by induction on the structure 
of the Gp formula. For the converse claim, let S be a Biichi automaton. We 
construct a guarded ^-calculus formula that is equivalent to the formula 3B. For 
notational convenience, we present the formula in equational form [10]; it can be 
easily converted to the standard representation by unrolling the equations, and 
binding variables with p or i^-fixpoints. For each set R G 2^ , let i/jr abbreviate 
the formula /\R /\ I ^ C II\R}. For each state s of B, we introduce a 

propositional variable Xg. The equation for Xg is 

=A |s4s'}, 

where A = if s € E is an accepting state, and X = p otherwise. The top-level 
variable is Xs„, where sq is the initial state. The correctness of the procedure 
follows from [6]. An equivalent construction is given in [12]. 

Theorem 1. The logics Gp and Ebl are equally expressive. 

From Proposition 2, and since the fully abstract semantics of Ebl is trace equiv- 
alence, we conclude the following. 

Corollary 1. Observation refinement (Aqr) terminates on the symbolic theory 
of a transition structure K. iff the trace-equivalence relation of K. has finite 
index. 

When the symbolic semi-algorithm for /r-calculus model checking is applied 
to an input in guarded form, then it computes only regions also computed by 
observation refinement. It follows that symbolic model checking for the guarded 
fragment of the ^-calculus terminates on all transition structures with finite 
trace-equivalence quotients. 

4 Symbolic LTL Model Checking 

4.1 Mu-Calculus Based Symbolic Model Checking for LTL 

The formulas of linear temporal logic (Ltl) are generated inductively by the 
grammar 



ip ::= 



7T \^ip I ipiC ip2 I Ot I TlUip2, 
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where tt is an observable, Q is the next operator, and U is the until oper- 
ator. From these operators, additional operators such as C>ip= (trueU^p) and 
□(/j = can be defined as usual. Formulas of Ltl are interpreted over 

traces [14]. We extend the interpretation to states existentially, an Ltl formula 
ip holds at a state g of a transition structure 1C if there is a source-g run r such 
that the trace ((r)) satisfies the formula p. The logic Ltl admits abstraction, and 
trace equivalence is a fully abstract semantics for Ltl. The expressiveness of Ltl 
lies strictly between Ebl and Efl. In particular, for every Ltl formula i^, we 
can construct a Biichi automaton such that |</3 ]a: = for all transition 

structures 1C [31]. We call B^p the tableau automaton of p. 

This suggests the following symbolic semi-algorithm the p-calculus 

based algorithm for Ltl model checking: given an Ltl formula p, first construct 
the tableau automaton B^,, then convert 3Bip into the guarded fragment of the p- 
calculus (using the procedure described above), and finally evaluate the resulting 
G/i formula on the given transition structure (using Apf). The final step requires 
only Pre operations and intersections with atomic regions. 

Theorem 2. For a transition structure 1C with a symbolic theory, and an Ltl 
formula p, the symbolic semi- algorithm terminates and computes kk if 

the trace-equivalence relation of K, has finite index. 

4.2 Product- Automaton Based Symbolic Model Checking for LTL 

Traditionally, a different method is used for symbolic model checking of Ltl 
formulas [9]. Given a state g of a finite-state transition structure JC, and an Ltl 
formula p, the question if g g kk be answered by constructing the product 
of 1C with the tableau automaton B^, and then checking the nonemptiness of a 
Biichi condition on the product structure. A Biichi condition is an Ltl formula 
of the form OOf), where is a disjunction of observables; therefore nonemptiness 
can be checked symbolically by evaluating the equivalent formula 

X = lyXi. pX2. (30 X2\/ A3Q Xi)) 

of the guarded fragment of the ^-calculus. 

To extend this method to infinite-state structures, we need to be more formal. 
Let 1C = (Q,n, {{■)), S) be a transition structure and let B,p = (S', 2^, — sq, E) 
be a tableau automaton. The product structure IC^, = (S x Q,S x II, {{■))ip,SO 
is defined as follows. Define (s',7r) g {{s,q)),p iff s' = s and tt g ((g)); that is, the 

state of the tableau automaton is observable. Define (s',g') g S,p(s,q) iff s ^ s' 
and g' g 6(q) and ((g)) = R. Then g g kk> ^r g g Q, iff (so,g) g iDO^/ik^, 
where f) = VsgFttg/tP’’’’)’ perform symbolic model checking on the product 
structure, we need to ensure that from a symbolic theory for K, we can obtain 
a symbolic theory for lC,p. Let (27, be a symbolic theory for 1C. We choose 
as region representatives for the product structure IC^p the pairs of the form 
(s,(t), where s is a state of B^, and cr is a region representative for /C; that is, 
27^ = S' X 27. Define '~s,a'^,p = {(s,g) j g g '"cr”'}. Since the tableau automaton 
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is finite, it is easy to check that is a symbolic theory for Let 

be the product- automaton based algorithm for Ltl model checking which, 
given an Ltl formula ip and a transition structure /C, evaluates the Gp formula 
X (representing a Biichi condition) on the product structure K.^ (using A^). It 
is not difficult to see that if observation refinement terminates on /C in fc steps, 
then it also terminates on in k steps (if Aqr generates m regions on 1C, then 
it generates at most m • l^l regions on IC^,). 

Corollary 2. For a transition structure 1C with a symbolic theory, and an Ltl 
formula p, the symbolic semi- algorithm A^^-^ terminates and computes If 
the trace-equivalence relation of K. has finite index. 

Indeed, by induction on the construction of regions, one can show that for each 
region representative (s, a) computed in the product-automaton based algo- 
rithm, the variable Xs in the /i-calciilus based algorithm represents the region 
at some stage of the computation, and conversely, for each valuation R of 
the variable Xg in the /r-calciilus based algorithm, a region representative of 
{s} X i? is computed in the product-automaton based algorithm. Thus, the two 
methods are equivalent in the regions they generate. 



5 Rectangular Hybrid Automata 

5.1 Definitions 

Let M" be the n-dimensional Euclidean space. A rectangle r of dimension n is 
a subset of K” which is a cartesian product of (possibly unbounded) intervals, 
all of whose finite end-points are integral^. The projection of a rectangle r on 
its ith coordinate is denoted r^, so that r = nr=i The set of all n-dimensional 
rectangles is denoted 3?”. 

An n-dimensional rectangular automaton H consists of a finite directed 
multi-graph (V,E), three vertex labeling functions init: E ^ inv: V 3?”, 
and flow: V — > 3?", and three edge labeling functions pre: E — > 3J", post: E — > 3J”, 
and jump: E — > 'A [22]. The vertices I CV specify the discrete states of the 

automaton; the edges e G E specify the discrete transitions. The initialization 
function init specifies the possible initial states of the automaton. If the automa- 
ton starts in vertex £, then its continuous state must be in init{£). The invariant 
function inv and the flow function flow constrain the continuous time evolution 
of the automaton. In vertex £, the continuous state nondeterministically fol- 
lows a smooth trajectory within the invariant region inv{£). At each point, the 
derivative of the trajectory must lie within the flow region flow{£). The edges 
are constrained by the pre-guard function pre, the post-guard function post, and 
the jump function jump. The edge e = {£, £') may be traversed when the current 
vertex is £ and the continuous state lies within pre{e). For each i € jump(e), 
the Ah coordinate of the continuous state is nondeterministically assigned a new 
value in the postguard interval post{e)i. For each coordinate i ^ jump{e), the 



3 



It is straightforward to permit intervals with rational end-points. 
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continuous state is not changed, and must lie within •post(e)i. We require that for 
every edge e = and every coordinate i = 1, . . . ,n, if flow{£)i yf flow{£')i, 

then i € jump(e). This condition is called initialization in [22], and it is shown 
there that it is necessary for simple reachability questions to be decidable. 

With a rectangular automaton H, we associate an infinite-state transition 
structure ICh = (Q, V, ((•)), 6) as follows. The states in Q are pairs {£, x) consist- 
ing of a discrete part £ G V and a continuous part x G K" such that x G inv(v) . 
The observables are the vertices, and {{£,x)) = £. We have (^',x') G 6{{£,x)) iff 
either (1) [time transition of duration t and slope d] £' = £, and x' = x -|- t • d 
for some real vector d G flow{£) and some real t >0 such that for all 0 < t' < t, 
(x -I- t' • d) G inv{£); or (2) [discrete transition along edge e] e = {£,£') G E, 
and (^, x) G pre{e), and x'^ G post{e)i for all i G jump{e), and x'i = x^ for 
all i ^ jump(e). The runs and traces of H are inherited from the underlying 
transition structure ICh- 

A natural symbolic theory for the rectangular automaton H is the follow- 
ing. Regions are represented as sets E = {{£, f) \ £ G V} of pairs, where £ is 
a vertex and / is a quantifier-free formula in the theory of reals with addition, 
Th(R, 0, 1, -I-, <), over the n variables xi, . . . , The atomic sentences in this 
theory are the linear inequalities; thus the continuous part of a region is repre- 
sented by a boolean combination of linear inequalities. The Pre operation can be 
described in the theory using quantifiers, and since the theory permits quantifier 
elimination, the quantifier-free formulas suffice as region representatives [4]. The 
emptiness and membership checks are also decidable. The tool HyTech [19] im- 
plements symbolic semi-algorithms for analyzing rectangular (and more general 
hybrid) automata using this symbolic theory. In particular, the symbolic semi- 
algorithms Apr, Aor, and A^ are all readily programmable using the scripting 
facility of HyTech. 

The variable Xi of the rectangular automaton H is a, finite-slope variable if 
for each vertex £ G V , the interval flow{£)i is a singleton. If flow{£)i = [1, 1] 
for all vertices £, then Xi is called a clock. The rectangular automaton H has 
deterministic jumps if for each edge e G E, and each coordinate i G jump{e), the 
interval post{e)i is a singleton. If El has deterministic jumps and x\, . . . ,Xn are 
all finite-slope variables, then El is a singular automaton. If H has deterministic 
jumps and Xi,. . . ,Xn are all clocks, then H is called a timed automaton [2]. 

5.2 Symbolic Model Checking 

It can be shown that the bisimilarity relation of the transition structure ICh 
has finite index for every singular automaton H [2,1]. This implies that we can 
check /r-calculus properties symbolically on timed and singular automata [24]. 
For rectangular automata, dimension 2 is enough to have bisimilarity degenerate 
into equality on states [17]. However, the results of [22] show that the trace- 
equivalence quotient of ICh is finite for every rectangular automaton H . From 
Corollary 1, we get the following result. 

Theorem 3. Observation refinement (Aor) terminates when applied to the 
symbolic theory of a rectangular automaton. 
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Corollary 3. Symbolic G/i model checking, fx-calculus based symbolic Ltl model 
checking, and product- automaton based symbolic Ltl model checking all termi- 
nate for rectangular automata. 

In practice, we are interested in the divergent runs of a rectangular automaton, 
i.e., those runs on which time advances beyond any bound. Formally, a run 
(.^0, Xq)(£i, xi) ... of a rectangular automaton is divergent if the infinite sum 

I i > 0 and x^+i) G is a time step of duration U} 

diverges. To restrict our attention to divergent runs, we can modify an n- 
dimensional rectangular automaton H in a, standard way [3]. We add an addi- 
tional clock variable at coordinate n-l-1, so that the dimension becomes n-|-l. For 
each vertex i gV, we introduce a new vertex itick and two edges e = {£, iuck) and 
e' = {£tick,£)- Define pre{e)i = post{e) = pre{e')i = post(e') = M for 1 < i < n; 
pre(e)„+i = posf(e)„+i = pre(e')n+i = 1, jump{e)n-ei = 0, jump{e') = {n -b 1}, 
and post{e')n+i = 0. This construction ensures that the added clock is reset to 
0 every time its value reaches 1. Then, the divergent runs are those for which 
the formula if = \j iuck is true infinitely often. To check if an Ltl formula 
ip holds on some divergent run of H, we instead check that the Ltl formula 
(□O')/;) A ip holds on any run of the extended automaton. 

In [22] , the proof that the trace-equivalence relation has finite index for every 
rectangular automaton H proceeds in two steps. First, the authors construct a 
singular automaton H' which forward simulates H, and is backward simulated 
by H . This implies that the trace-equivalence quotient for finite traces has finite 
index. In a second, involved step, they prove that a finite trace-equivalence quo- 
tient for finite traces implies a finite trace-equivalence quotient for infinite traces 
as well. The results of this paper allow a more direct proof, which immediately 
gives the desired result for infinite traces. It suffices to show that observation 
refinement (Aqr) terminates on the transition structure of H. As in [22], it 
can be argued that every Pre operation on JCh corresponds in a precise sense 
to a Pre operation on JCw- Since the bisimilarity quotient of JCr' is finite, this 
implies that Pre operations on JCh can also generate only a finite number of 
distinct regions. There is only a finite number of observables (corresponding to 
the vertices of PI). So the intersection of a region with an atomic region is simply 
the projection of the region onto a discrete part. Thus, the restricted intersec- 
tion operation of Aqr does not give rise to any new continuous parts of regions 
beyond the ones already computed. It follows that Aqr terminates on K-h- This 
result is sharp: for simple extensions to the model of rectangular automata, even 
backward reachability (Ao) may not terminate [22]. 



5.3 Example: Assembly Line Scheduler 

We describe an assembly line scheduler that must assign elements from an in- 
coming stream to one of two assembly lines [21]. The stream has an inter-arrival 
time of four minutes. The lines process the parts at different speeds: on the first 
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Fig. 1. Two assembly lines modeled as a rectangular automaton 



line, jobs travel between one and two meters per minute, while on the second, 
jobs travel between two and three meters per minute. The first line is three me- 
ters long and the second line is six meters long. Once a line finishes processing a 
job, it enters a clean-up phase, and no jobs may be assigned to it while it cleans 
up. The clean-up time is two minutes for the first line and three minutes for the 
second line. The system may accept a job if both lines are free, and at most one 
is cleaning up. If the system is unable to accept a job, it shuts down. 

The system is modeled by a rectangular automaton as shown in Figure 1. 
There are four discrete states: in idle, no jobs are being processed; in linei 
{line 2 ), line-1 (respectively, line-2) is processing a job, and in shutdown, the 
system is shut down. The variable xi (respectively, X 2 ) measures the distance a 
job has traveled along line-1 (respectively, line-2). The variable ci ( 02 ) tracks the 
amount of time line-1 (line-2) has spent cleaning up after its last job. Finally, 
the variable r measures the elapsed time since the last arrival of a job. 

We modeled the system in HyTech. Backward reachability (^lo) terminates 
in set of states that can reach the unsafe vertex shutdown. We added a prepro- 
cessor to HyTech which takes an Ltl formula and generates a script to evaluate 
an equivalent formula. We then considered the property that any feasible 
schedule must choose line-1 infinitely often. To establish this requirement, we 
checked that the formula (OD^Zmei) A shutdown) does not hold on any di- 
vergent run from the vertex idle (if this formula were to hold on some divergent 
run, then there would be a schedule that assigns jobs to linei only finitely many 
times, and still enforces that the system never shuts down). This required 0.39 
seconds of CPU time on a DEC alpha with 2G RAM. 
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Abstract. A new data-structure called RED (Region- Encoding Dia- 
gram) for the fully symbolic model-checking of real-time software sys- 
tems is proposed. RED is a BDD-like data-structure for the encoding of 
regions [2]. Unlike DBM which records differences between pairs of clock 
readings, RED only uses one auxiliary binary variable for each clock. 
Thus the number of variables used in RED is always linear to the num- 
ber of clocks declared in the input system description. Experiment has 
been carried out to compare RED with previous technologies. 



1 Introduction 

Fully symbolic verification of real-time systems is desirable with the promise of 
space and time efficiency through intense data-sharing in the manipulation of 
state space representations. We propose Region- Encoding Diagram (RED) as the 
new data-structure for such a purpose. RED is a BDD-like data-structure [5,8] for 
the encoding of regions [2] . The ordering among fractional parts of clock readings 
is explicitly encoded in the variable ordering of RED. To record sets of clock 
readings with the same fractional parts, we add one auxiliary binary variable 
per clock. Thus in RED, the number of variables used is linear to the number 
of clocks. Like BDD[8], RED is also a minimum canonical form with respect 
to a given variable ordering. It is also efficient for representing unions of zones. 
Experiments have shown better space efficiency against previous technologies 
like DBM (Difference-Bounded Matrix) [10]. 

We assume that system behavior is described as a set of m symmetric pro- 
cesses, identified with integers 1 to m, running different copies of the same pro- 
gram. Each process can use global and local variables of type clock, discrete, and 
pointer. Pointer variables either contain value NULL (0 in fact) or the identifiers 
of processes. Thus in our representation, we allow complicate dynamic networks 
to be constructed with pointers. We restrict that each process can declare at most 
one local clock and there is no global clock. The ordering of fractional parts of 
clock readings is encoded in RED with the following normality condition. 

* The work is partially supported by NSC, Taiwan, ROC under grant NSC 89-2213- 
E-001-002. 
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“For any two local clocks with I < i < j < m, of processes i 

and j respectively, either a;[z] does not have a greater fractional part than 
a;[j] does or a;[j] is greater than the biggest timing constant used in the 
input system description and specification. ” 

A state satisfying the normality condition is called a normalized state. With RED 
technology, we only work with the normalized images of states in runs. After a 
clock reading advancement or a clock reset operation, we may have to permute 
the process identifiers to maintain state normality. Thus our data-structure is 
perfect for symmetric systems with symmetric specifications. 

Our innovation is that we use one bit for each clock to encode the order- 
ing among the fractional parts of clock readings in the region construction [2]. 
Compared to the classic DBM [10] , RED provides data-sharing capability of fully 
symbolic manipulation. In a DBM-based model-checker, since matrices and BDD 
are two different types of data-structure, we are forced to use a pair of BDD and 
matrix to represent a region. As a result, the set of regions are forced to be 
represented as an explicit directed graph which does not succinctly abstract out 
the interaction pattern in the pairs and whose size inevitably grows exponen- 
tially with timing constant magnitude and concurrency size. Moreover, to get 
region canonical representations, DBM-technology usually resorts to the pro- 
cessing of convex hulls which are equivalent to conjunctions of clock inequalities. 
Thus it may be necessary to break a big disjunction down to exponentially many 
conjunctions. Such breaking-down can be a source of inefficiency. But since the 
present RED algorithms derive time step next-state RED’s at very tiny steps, 
DBM may have better verification performance with systems with big timing 
constants. 

Newer technology of NDD[1] and CDD[7] use binary inequalities of the form 
a;[z] — x[j] < c. NDD uses binary encoding for the possible values of c while CDD 
uses multiple value-ranges to record them. However, the number of variables in 
their data-structure is likely to be quadratic to the number of clocks used in 
the systems. The number of variables used in our RED technology, on the other 
hand, is always linear to the number of local clocks. 

Here is our presentation plan. Section 2 defines the language for system be- 
havior description. Section 3 formally presents our data-structure scheme. Sec- 
tion 4 shows how to maintain RED’s after clock reading advancements and clock 
reset operations. Section 5 compares RED technology with previous ones by per- 
forming experiments on several benchmarks. 



2 Real-Time Software Systems 

We assume a real-time software system to be composed of a set of concurrent 
processes running different copies of the same program. Given a system of m 
processes, the processes are indexed with integers 1 through m which are called 
process identifiers. NULL is actually integer 0 and is used as the special null 
process identifier in data-structure construction. The program is presented as a 
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Fig. 1. Fischer’s timed mutual exclusion algorithm 



timed automaton\ 2 \ equiped with global and local variables of type clock, dis- 
crete variable, and pointer. A global variable can be accessed by all processes 
while a local variable can only be accessed by its declaring process. Clocks can 
hold reals, can be tested against integers, and can be reset to zero during transi- 
tions. Only one local clock per process is allowed and no global clock is allowed. 
Discrete variables can hold integer constants. Operations on discrete variables 
are comparisons and assignments with integer constants. A special local discrete 
variable mode is used to record the operation mode of the executing process. 
Pointer variables can hold NULL or process identifiers. Operations on pointers 
are comparisons and assignments with NULL or local process identifiers (the one 
of the executing process). 



2.1 Syntax 

Given a system of m processes with variable set X, we can define global state 
predieates and loeal state predieates. Global state predicates are used to specify 
initial conditions and safety properties and are presented with a process identifier 
attached to each local variable to distinguish which local references are for which 
processes. The syntax of a global state-predicate p is: 

rj ::= false | a; ~ c | y = NULL \ y = c 

I x[i] ~ c I y\i] = NULL \ y[i] = c \ \ rji \/ r]2 

Variables appended with square brackets are local variables while those not are 
global variables, x is either a clock variable or a discrete variable, y is a pointer 
variable, c is a natural constant. ~ is an inequality operator in {<, <, =, >, >}. 
z is a process identifier constant in ^ and V are Boolean negation and 

disjunction respectively. Parentheses can be used to disambiguate the syntax. 
Standard shorthands are true = -^false, zyi A 772 = ^((^? 7 i) V (^772)), and rji — > 
V 2 = hm) V 772. 

Local state-predicates are used to describe invariance and triggering con- 
ditions in the automata. Their syntax is very much like that of global state- 
predicates except that all occurrences of process identifier constants are replaced 
by the symbolic process identifier p which is to be interpreted as the process 
identifier of the executing process. 

In figure 1 , we have an example automaton for Fischer’s timed mutual ex- 
clusion algorithm. 
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Here, we have a global pointer lock and a local clock x[p] for process p with p 
as the symbol for the identifier of the executing process. On each transition 
(arc), we label the triggering condition and assignment sequence. Testing on and 
assignments to local discrete mode are omitted from the transitions for simplicity. 
a and 5 are two integer parameters to be substituted in implementation. Mutual 
exclusion to mode 3 is maintained when a < 5. 

The formal syntax of a real-time software system S is given as a triple 
{A, m, I) where H is a timed automaton equiped with various variables as men- 
tioned in the above, m is the number of processes in the system, and / is a 
global state-prediate for the initial condition. A is formally presented as a timed 
automaton A = {X, A, Q, p, E, r, tt) with the following restrictions. X is the set 
of variables. A maps each variable in X into one of the following five types: local 
clock, global discrete, local discrete, global pointer, and local pointer. Q is the 
set of operation modes (or control locations) . We assume that the elements in Q 
are indexed from 0 to \Q\ — 1. /i is a function from [0, |Q| — 1] such that for all 
q G [0, IQ I — 1], p{q) is a local state-predicate describing the invariance condi- 
tion at the g’th operation mode. Also we require that there is a special local 
discrete variable mode which always record the current operation mode index of 
a process. 

E C Q X Q is the set of transitions, t is a function from E such that for all 
e € E, r(e) is a local state-predicate describing the triggering condition of e. tt 
is a function from E such that for all e G if, 7r(e) is a sequence of assignments 
a of the syntax form: 

a ::= L := R] 

L::=x\ x[p] \ y \ y[p] 

R::= c\ NULL \ p \ x \ x[p] \ y \ y[p] 

Such an assignment means that the value of R is assigned to variable L. The 
restriction is that constants or variables cannot be assigned to variables of dif- 
ferent types. For example, if L is not of type pointer, then R cannot be NULL, 
p, or any pointer variables. 

2.2 Semantics 

Definition 1. states Suppose we are given a real-time software system S = 
{A,m,L) with A = {X, X,Q, p, E,t,tt) . A state v is a, mapping from X x 
{0, . . . , m} such that 

• for every global pointer x G X, v{x, 0) € {NULL} U {1, . . . , m|; 

• for every global discrete x G X, v{x, 0) G Af; 

• for every local clock x G X and i G {!,..., m|, iy{x, i) G TZ; 

• for every local pointer x G X and i G {!,..., m|, i^(x,i) G {NULL} U 

{l,...,m}; 

• for every local discrete x G X and i G {!,..., m}, /y(x, i) G Af. || 

For any t G 7Z, is the state identical to i' except that for every local clock 
a:[z], i^(x, i) + t = (i^ + t)(x, i). For an atomic assignment L := R; and a process 
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identifier z, u[L := R ] , z] is the new state obtained by letting process z executing 
L := i?; in v. It is identical to v except that {v[L := i?; , i]){L, i) = v{R, i). Given 
a sequence [3 of assignments and a process identifier z, zz[/ 3 , z] is defined in the 
following inductive way. 

• If /3 is empty, then zz[/ 3 , i] = v. 

• If /3 = aP', then v[P,i] = (zz[a, z])[/ 3 ', z]. 

Given a global state predicate rj and a state v, we say that v satisfies 77, in 
symbols \= ij, if and only if the following inductive restrictions hold. 

• zz ^ false. 

• zz 1= a: ~ c iff iy(x, 0) ~ c. 

, ly j=y = NULL iff v{y, 0 ) = NULL. 

• zz 1= z/ = c iff zz(z/, 0) = c. 

• V \= x[i] ~ c iff v{x, i) ~ c. 

• V \= y [i] = NULL iff iy{y, z) = NULL. 

• ly \= y [i] = c iff zz(z/,z) = c. 

• zz 1= ^rji iff it is not the case that ly \= rji. 

• zz 1 = zyi V 772 iff either zz ^ 771 or zz ^ 772. 

The satisfaction relation between a local state predicate 77 and a state zz by 
process z, in symbols zz, z |= 77, can be similarly defined. 

• Z7, z ^ false. 

• Z7, z 1= a; ~ c iff iy(x, 0) ~ c. 

• v,i'^y = NULL iff v{y, 0 ) = NULL. 

• Z 7 , z 1 = 7/ = c iff zz(z/, 0 ) = c. 

• Z 7 , z 1 = a; [73] ~ c iff v{x, i) ~ c. 

• Z 3 , z 1 = y[p] = NULL iff zz(z/, z) = NULL. 

• Z 3 , z 1 = 7 /[p] = c iff zz(z/, z) = c. 

• Z3, z 1= ^771 iff it is not the case that zz, z ^ 771 . 

• Z3, z 1 = 771 V 772 iff either iz, z ^ 771 or zz, z |= 772 . 



Definition 2. runs Given a real-time software system S = {A, m, L) with A = 
{X, X,Q, p, a v-run is an infinite sequence of state-time pair 

■ ■ ■ i^kUk) such that zz = zzg, tgU ■ • ■ ffc is a monotoni- 

cally increasing real- number (time) divergent sequence, and for all A: > 0, 

• for all t G [ 0 ,tfe+i - tk] and I < i < m, Vk + t,i \= Vo<g<|Q| (“°^®[p] = 
q A p{q)); and 

• either zz^, -|- {tk+i — tfc) = k'k+i; or there are z G ttz} and e € E such 

that zzfc -I- {tk+i - tk)A h r(e) and (zz^ -|- {tk+i ~ Afc))k(e), z] = Vk+i- II 

A run p = (izg, to)(zzi, U) . . . (zzfe, ffe) of S satisfies safety global state 

predicate 77, in symbols p ^ 77, iff for all fc > 0 and tk <t < tk+i, Vk + t\= rj. We 
say S satisfies 77, in symbols S' |= 77, iff for all zz-runs p such that zz |= /, p |= 77. 
In case that S ^ 77, we say S violates rj. 
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2.3 Normalized Runs and a Permutation Scheme 



Given a constant r £ TZ, int{r) is the integer part of r while frac{r) is the 
fractional part of r. Let Cs be the biggest integer constant used to compare with 
a local clock in the system description S. The normality condition is restated 
here: 

“Suppose the local clock is x in a system S = {A,m,I). A state v 
of S is normalized iff for any 1 < i < j < m, either v{x,j) > Cs 

or ira,c{v{x,i)) < frac(j^(a;, j)). ” 

Thus, in a normalized state, we can conceptually divide the process identifiers 
into several segments in the following pattern. 



1 , ' 
* 1 , . 

*1 + 1 ) 1 



* 2 , 



1) < Cs A ... A v{x, ii) < Cs 
A frac{v{x, 1)) = . . . = frac{v{x, ii)) frac{v{x, i\ + 1)) 

v(x^ + 1) < Cs A . . . A v(x^ 12 ) < Cs 
A frac{iz{x, ii + 1)) = . . . = frac{v{x, i^)) yf frac{v{x, 12 + 1)) 



+ 1) I 



ik+i + 1 ) 



m 



v{x, ik + l)<Cs i>{x, ifc+i) < Cs 

A frac{i'{xAk + 1)) = . . . = frac{v{x,ik+i)) 



'{x, ik+i + 1) > Cs A . . . A iy{x, m) > Cs 



The last segment contains identifiers of those processes whose local clock readings 
are greater than Cs- The processes with identifiers in a segment other than the 
last one all have the same fractional part in their clock readings which are no 
greater than Cs- 



Definition 3. normalized runs Given a run p = {v[),te)){viAi) - - - {k'kAk) - - - 
of a real-time software system S = {A, m, /), a normalized run p of p is a mapping 
from Af X TZ such that for every k G Af and 0 < t < t^, p{k, t) is a normalized 
state of izk + t- II 



After each transition or clock readings advancement, a normalized state can 
be changed to an unnormalized one and there can be more than one identifier 
permutation whose application can maintain the normality of states. We propose 
the following permutation rules which can simplify our tool implementation. 

1. When process i resets its local clock with a transition, we have to 

— change the identifier of process f to 1 (with global and local variables 
updated according to the transitions.); and 
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— for every 1 < j < i, change the identifier of process j to j ' + 1; and 

— for every i < k < m, keep the identifier of process k unchanged 

in the destination state to make it normalized. The permutation can be 
viewed as an identifier movement from t to 1 with displacement 1 — i. 

2. When there is no integer clock readings < Cs in the source state and some 
clocks will advance from noninteger readings < Cs to integer readings, we 
first have to identify the segment of identifiers of those processes with such 
clocks. This is the segment right preceding the last segment which contains 
identifiers of processes with local clock readings > Cs- Suppose, we find out 
x[j ], . . . , x[k] are such clocks. Then in the destination state, 

— for all j <i < k, the identifier of process i is changed to f — j + 1; and 

— for all 1 < f < j, the identifier of process i is changed to i + k — j + 1; 
and 

— for all k < i < m, the identifier of process i is unchanged 

to make it normalized. The permutation can be viewed as an identifier seg- 
ment movement from [j, k] to [1, k — j + V\ with displacement 1 — j . 

3. When some clocks advance from integer to noninteger readings, we first 
have to detect if some of those clocks advance their readings from Cs to 
beyond Cs- Suppose, we find out that x[j ], . . . , x[k] are such clocks. Then in 
the destination state, 

— for all j < i < k, the identifier of process i is changed to i + m — k; and 

— for all 1 < t < j, the identifier of process i is unchanged; and 

— for all k < i < m, the identifier of process i is changed to i + j — k— 1 
to make it normalized. The permutation can be viewed as an identifier seg- 
ment movement from [j, k] to [j + m — k, m] with displacement m — k- 

4. In all other cases, the identifiers of all processes stay unchanged to satisfy 
normality. 

However, there is one thing unclear in the above-mention permutation scheme. 
That is, in the third item, how do we know that those processes with clock 
readings = Cs will appear with consecutive process identifiers ? That is the good 
thing about this permutation scheme and can be established by the following 
lemma. 

Lemma 1. In the permutation scheme presented in the above, inside all seg- 
ments of identifiers of processes whose clock readings are < Cs and share the 
same fractional parts, the process identifiers are arranged according to monoton- 
ically increasing order of the local clock readings- 

Proof : True because every time when we reset a local clock, we change the 
identifier of the transiting process to 1 . Thus the later a process resets its clock, 
the earlier its identifier appears in a segment. || 



Definition 4. Symmetric global state predicate Given a global state pred- 
icate rj and a permutation 9 of process identifier 1 through m, rjO is a new global 
state predicate obtained from rj by renaming process identifiers according to 9- 
A global state predicate p for m processes is symmetric iff for any permutation 
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Fig. 2. Data structure implementation of a node in RED 

0 of 1 through m, rj equals to rjd according to commutation laws of Boolean 
algebra. || 

We want to establish the soundness of our RED technology with the following 
lemma. 

Lemma 2. ; Given a state v of a real-time software system S = {A^m,I) and 
a symmetric global state predicate rj, for any normalized image v' of u , v \= rj iff 
v' p. 

Proof : Suppose the process identifier permutation that changes v to v' \s 9. 
Then i' \= rj has the same truth value as v' |= (rjO) . But rjO is equal to rj according 
to commutation laws of Boolean algebra. Thus the lemma is proven. || 



3 Region-Encoding Diagram 

RED is a data-structure for representing set of normalized states. In the imple- 
mentation aspect, it resembles CDD[7] and each node in RED has the structure 
shown in figure 2. Such a node is used to evaluate the truth value of a formulas 
from variable v. The outgoing arcs are labeled with lower and upper bounds of 
integer parts (note, only integer parts) of values of variable v and direct to 
the red’s for the subformulae true in the corresponding ranges of v’s values. 
For example, if the second arc from left in figure 2, is labeled with [7,9], then 
subformulus represented by the RED rooted at vi must be true when the integer 
part of v’s value is in [7,9]. The ranges labeled on arcs from a RED node are 
required to be disjoint. 

The lower and upper bounds of outgoing arcs are chosen according to the 
following rules. For clock variables, we define constant Os = Cs + 1 which 
symbolically denotes a clock reading greater than Cs ■ Thus the lower and upper 
bounds of outgoing arcs from RED nodes of clock variables are chosen from 
elements in {0, . . . , CsjUlOs, (X)} which is sufficient for the regions construction 
in [2]. For discrete variables, the lower and upper bounds of outgoing arcs are 
chosen from those constants assigned to and compared with the variable in both 
the automaton and the specification. For pointer variables, the lower and upper 
bounds of outgoing arcs are chosen from NULL and integers 1 through m. 
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Given an automaton A with variable name set X, the variable set in the 
RED for an m process system is 

{x I a; G X; a; is global} U{ a; [*] | a; G X;a; is local; 1 < i < m}Ll{K[i] | 1 < i < mj 

Here k is the name for an auxiliary local binary discrete variable name used to 
encode the fractional part orderings among clock readings. According to Alur 
et al’s region graph construction [2], the state-equivalence relation for model- 
checking is determined by the following three factors: 

• the discrete information of each state, 

• the integer parts of clock readings < Cs- 

• the ordering among the fractional parts of clock readings < Cs ■ 

Our innovation is that we use one bit (k) for each clock to encode the ordering 
among the fractional parts of clock readings in normalized states. For each clock, 
say x[i] of process i, k[i\ is true in a normalized state s if and only if s(a:[z]) < Cs 
and either 

• 1 = 1 and frac{s{x[i])) = 0, i.e., s(x[i]) is an integer; or 

• i> 1 and/rac(s(a;[i— 1])) = /rac(s(x[i])), i.e., the fractional parts of s(a;[i—l]) 
and s(a;[t]) are the same. 

With such definition of data-structure and appropriate permutations of process 
identifiers after clock reading advancements and clock reset operations, we are 
able to represent the regions of timed automata [2]. As for the other input 
variables, local or global, we simply copy them as the variables in our RED. Thus 
given a real-time software system S = {A,m,I) with A = (A, A, Q, /i, E, r, tt), 
the number of variables used in our RED is 0{m\X\ + m). 

For example, we may have 8 processes in a normalized state with x[l] = 
Q,x[2] = 3,a;[3] = 1.3,a;[4] = 1.456, a;[5] = 9.456, a;[6] = 20.7, x[7] = 38,a;[8] = 
IOtt while Cs = 13. The readings of clocks and values of «:[i]’s are shown in the 
following. 

il234 5678 

■^“0 3 1.3 1.456 9.456 20.7 38 IOtt 

k[i\ true true false false true false false false 

4 Manipulations on RED 

4.1 Boolean Operations 

The Boolean operations on RED’s follow the same style in Bryant’s BDD ma- 
nipulations [5,7,8]. We present procedure REDop{op, D^, Dy) in table 4.1 to 
illustrate the idea in the implementation of such an operation. For convenience, 
we use [l,u]D to denote an outgoing arc whose lower bound is I, upper bound 
is u, and the subformulus RED is D. Also, D.v denotes the index, of D’s variable, 
used in the variable-ordering of the RED. 

We should point out that the algorithm shown in table 4.1 is for simplicity 
and clarity of algorithm presentation and is not for efficiency. Our implemen- 
tation is more efficient in that it records which pairs of , Dy have already 



166 Farn Wang 



Table 1. Algorithm for computing D^op Dy 

REDop{ op, D,^,Dy){ 

(1) if op= AND, 

(1) if Dx is true, return Dy; 

(2) else if Dy is true, return D^; 

(3) else if either Dx or Dy is false, return false; 

(2) else if op— OR, 

(1) if either Dx or Dy is true, return true; 

(2) else if Dx is false, return Dy; 

(3) else if Dy is false, return Dx; 

(3) else { 

(1) Construct a new RED node D with D.v = mm{Dx-V, Dy.v); 

(2) if Dx-V < Dy.v, then for each outgoing arc \l,u]Dc of Dx, 
add an outgoing arc [l,u]REDop{op, Dc, Dy) to D. 

(3) else if Dx-V > Dy.v, then for each outgoing arc [i, u]Dc of Dy, 
add an outgoing arc [l,u]REDop{op, Dx, Dc) to D. 

(4) else for each outgoing arc [lx,Ux]D'x of Dx and outgoing arc [ly,Uy]Dy of Dy, 
if [max.{lx,ly),rnm{ux,Uy)] is nonempty, 

add an outgoing arc [ma,x{lx,ly),rnin{ux,Uy)]REDop{op, D'x, Dy) to D. 

(5) Merge any two outgoing arcs [/, u]Dc, [m + 1, u']Dc of D into one [i, u']Dc 
until no more merge can be done. 

(6) if D has more than one outgoing arcs, return D, 
else return the sole subformulus of D; 

} 

} 



been processed. If a pair of Dx,Dy has already been processed with procedure 
REDop{) before, then we simply return the result recorded in the first time when 
such a pair was processed. 



4.2 Preserving Normality after Transitions and Clock Reading 
Advancement 

RED is a data-structure for normalized states of real-time software systems. 
Transitions and clock reading advancements may change normalized states into 
unnormalized states. This section tells us how to symbolically do necessary pro- 
cess identifier permutation to preserve the normality of states. 

Given a local variable v[i] of process i, we assume that Varlndex{i,v) is the 
variable index of in RED. For convenience, we use process identifier 0 (NULL) 
for those global variables. That is VarIndex{0, v) returns a valid variable index in 
RED only when u is a global variable. As can be seen from the process identifier 
permutation scheme in subsection 2.3, segment movements are performed. We 
can thus define the following function which computes the new identifier of 
process i after such a segment movement. 
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NewProcId{i, j, k, disp) /* process identifiers j through k are to be 
moved with displacement disp. */ { 

(1) if i = 0, return 0; /* Global is always global. */ 

(2) else if j < i < fc, return(i + disp); 

(3) else a i < j + disp, return(i); 

(4) else if j + disp < i < j, return(f + k — j + 1); 

(5) else ii k < i < k + disp, return(i — {k — j + 1)); 

(6) else /* k+ disp < i */ return(i); 

} 

Due to page-limit, we shall only describe the algorithm for symbolic manipulation 
of a procedure ToInt{R), in table 2 in page 168, which generates a new RED 
describing the set of states obtained from those in R by advancing those clocks 
with biggest fractional parts to integers. In the algorithm presentation, for simple 
clarity, we use Boolean operation symbols like V,A to represent our procedure 
REDop(). Also for an atom like Z < y < w, it is implemented by constructing 
the following RED. 




Of course, when [0,Z — 1] (or [m -|- l,oo]) is empty, the corresponding arc 
disappears. Symbolic manipulation procedures for next state set after transitions 
and clock reading advancement from integers to fractionals can all be defined 
similarly. 

5 Experiments 

We have experimented to compare RED technology with previously published 
performance data in two reports [4,6] that compared performances of various 
model-checkers respectively on two versions of Fischer’s timed mutual exclusion 
algorithm as shown in Figure 3. The property to be verified is the safe property: 
at any moment, no more than one process are allowed in mode 3. 

UPPAAL’s version has bigger timing constants while Balarin’s version allows 
repetitions. 

UPPAAL is based on DBM technology and has been well accepted as one 
of the most efficient model-checkers for real-time systems. It has been used to 
successfully verify many communication protocols. Recently, CDD technology 
was proposed to enhance the performance of UPPAAL[7j. However, further 
reports are yet to be seen. In [6], UPPAAL was compared with many other 
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ToInt(R) /* R describes the state set before advancing those clock readings with 
biggest fractional parts to integers. */ { 

(1) D false-, 

(2) For 1 < i < m and i < j < m, do { 

(1) Construct the condition K that 

• there is no clock whose reading is an integer < Cs', and 

• processes i to j are those with biggest fractional parts 
in their clock readings. 

(2) D := D\/ RecToInt{K A R, 

} 

(3) Return(D); 

} 

RecToInt{K,i,j) { 

(1) If K is either true or false, return K-, 

(2) Get the process identifier k of K.v, /* k — 0 when v is global. */ 

(3) Generate the name x of variable K.v of process NewProcId(k,i,j, 1 — i)); 

(4) K' -.= false-, 

(5) switch on type of K.v { 

(6) case LOCAL.CLOCK: 

(1) it i < k < j, then for each outgoing arc [l,u]D' of K, 

K' -.= K' \/ {I + 1 < X < u 1 f\ RecToInt{D' , i,j))-, 

else for each outgoing arc [l,u]D' of K, 

K' -.= K' \/ {I < X < u f\ RecToInt{D' ,i, j))-, 

(2) return(A"); 

(7) case K\k]-. 

(1) if NewProcId{k, i,j, 1 — i) = 1, 

(1) then with outgoing arcs {h,u\]Di, . . . , [ln,Un]Dn of K, 
return(«:[l] = true f\\J .^^^^^RecToInt{Dh,i,j))-, 

(2) else for each outgoing arc [l,u\D' of K, 

K' := K' \/ (I < K[NewProcId(k, i, j, 1 — i)] < u A RecToInt{D' , i, j))-, 

(2) return(A"); 

(8) case LOCALJDiscrete: 

(9) case GLOBAL_Discrete: 

(1) for each outgoing arc [l,u]D' of K, 

K' := K' \/ {I < X < u A RecToInt{D' , i,j))-, 

(2) return(A"); 

(10) case LOCAL JOINTER: 

(11) case GLOBALJOINTER: 

(1) for each outgoing arc [l,u]D' of K and each I < h < u, { 

(1) g := NewProcId{h,i, j, 1 — i); 

(2) K' -.= K' V (x = g A RecToInt{D',i,j))-, 

} 

(2) return(A"); 

} 



Table 2. Symbolic manipulation procedure for time-steps from regions with no 
integer clock readings < Cs to those with ones 
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global pointer 1; local clock x; local discrete mode; 



/ = NULL ^ < 1 > 2 A ( = p^ 

(mode[p] = *^mode[p] = l) *^mode[p] = 2J *(mode[p] = 3) 

x[p] := 0; ''I ■■= p; ^ 



(a) UPPAAL’s version of Fischer’s algorithm 

global pointer /; local clock x: local discrete mode; 




(b) Balarin’s version of Fischer’s algorithm 



Fig. 3. Two versions of Fischer’s algorithm for experiments 



model-checkers like HyTech’s[3], Epsilon, and Kronos[13] on the automaton in 
figure 3(a). The experiments was reported to be performed on a Sparc-10 with 
128 MB memory (real plus swap). All other tools fail when the number of pro- 
cesses reaches beyond 5 while UPPAAL can verify the algorithm on 8 processes. 

We have implemented two version of RED on an Pentium II 366 MHz IBM 
notebook with 256 MB memory (real plus swap) running Linux. The tools are 
avaiable at: 



http : //www. iis . sinica. edu. tw/~f arn/red 



The first version is plain while the second version employs the clock-shielding 
reduction technique reported in [12,14]. Reduction clock-shielding replaces clock 
readings with oo in a state when along any runs from the state, it is deter- 
mined that such a reading will no longer be read unless the clock is reset. The 
performance is listed in the following table. 



version 


resources 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


no CS 


time 


0.19 


1.22 


6.5 


27 


105 


320 


888 


2323 


5556 


N/A 


N/A 


N/A 




space 


50 


212 


697 


1959 


4885 


10966 


22444 


42858 


77503 


N/A 


N/A 


N/A 


CS 


time 


0.17 


0.98 


4.4 


16.5 


50.3 


134 


325 


724 


1493 


3002 


5743 


10152 




space 


47 


161 


463 


1134 


2456 


4810 


8871 


15726 


26194 


41930 


64323 


95389 



“CS” means the version with clock-shielding reduction while “no CS” means the 
one without. The CPU time is measured in seconds. The space is measured in 
kilobytes and only includes those for the management of RED’s and 2-3 trees. 
“N / A” means “not available” which indicates that the corresponding experiment 
has not been performed. 

The time consumption is considerable bigger than that of UPPAAL [6] con- 
sidering the CPU clock rate difference. This is due to our implementation phi- 
losophy. We believe time is an unbounded resource while space is not. As can 
be seen from procedure ToInt(), no RED for the relation between current state 
and next state is computed. In practice, such a relation in RED can occupy a 
great many bytes. The next-state set RED is computed by analysis on different 
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situations of i and j. The sacrifice in CPU time pays off in the memory space 
efficiency. With twice the memory size used in [6], we are now able to verify the 
simplified Fischer’s algorithm with 13 processes. 

UPPAAL is a mature tool with a great arsenal of reduction technologies 
implemented. Our software at this moment only relies on minimal canonicality 
of RED to gain performance. Please note that the exponent base in our data 
seems to decrease with respect to concurrency size. This may imply that fully 
symbolic manipulation is more suitable for large system verification. In the fu- 
ture, with more reduction technique implemented for RED, we hope even more 
performance improvements will be observed. For example, the clock-shielding 
reduction indeed slowers down the state-space explosion problem exponentially. 
Still several simple reduction, like getting rid of FALSE terminal nodes in RED, 
can be implemented in the future version of RED to get constant factor of im- 
provement. 

In [4,15], weak and strong approximation technologies of symbolic verification 
are proposed and experiments are performed on algorithm in figure (b). We 
extend the performance data table in [4] to compare our tool with previous 
technologies. 



#proc 


strong 


weak 


KRONOS 


Wong-Toi 


RED(no CS) 


6 


155sec 


18sec 


1174sec 


74sec 


26sec/ 1374k 


7 


398sec 


48sec 


M/0 


164sec 


67sec/2488k 


8 


986sec 


116sec 


M/0 


375sec 


142sec/4242k 


9 


2220sec 


247sec 


M/0 


891sec 


303sec/6858k 


10 


M/0 


576sec 


N/A 


N/A 


558sec/10659k 


11 


N/A 


N/A 


N/A 


N/A 


1034sec/15673k 


12 


N/A 


N/A 


N/A 


N/A 


1724sec/22251k 


13 


N/A 


N/A 


N/A 


N/A 


2889sec/30593k 


14 


N/A 


N/A 


N/A 


N/A 


4492sec/41019k 


15 


N/A 


N/A 


N/A 


N/A 


7047sec/53737k 


16 


N/A 


N/A 


N/A 


N/A 


10782sec/69126k 


17 


N/A 


N/A 


N/A 


N/A 


15330sec/87431k 



The original table consists of the firt five columns and only reports the CPU time 
in seconds used by various tools. “M/0” means “out of memory.” KRONOS is 
also based on DBM technology while Wong-Toi’s tool is based on approximation. 
In our extension, each entry is composed of both CPU time (in seconds) and 
space (in kilobytes) used. The column extension is for time/space consumed 
without clock-shielding reduction. Balarin’s experiment is performed on Sparc 2 
with 128 MB memory while ours is performed on IBM Thinkpads with PII 366 
MHz and 256 MB memory. Be reminded that verification problems are of high 
space complexities in nature. The fact that RED-technology can handle much 
higher concurrency implies that it indeed control state-space explosion better. 
We believe that such performance is gained not only from utilization of system 
symmetry, but more importantly, from the data-sharing capability of RED. 
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6 Conclusion 

We propose to use one auxiliary binary variable for each clock in our new data- 
structure for fully symbolic model-checking of real-time software systems. Since 
we now have fewer variables in the fully symbolic manipulation, theoretically 
we can expect better verification performance. With better implementation of 
reduction techniques borrowed from BDD technology, we are hoping for further 
performance improvement. 
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Abstract. We show how the problem of verifying parameterized sys- 
tems can be reduced to the problem of determining the equivalence of 
goals in a logic program. We further show how goal equivalences can be 
established using induction-based proofs. Such proofs rely on a power- 
ful new theory of logic program transformations (encompassing unfold, 
fold and goal replacement over multiple recursive clauses), can be highly 
automated, and are applicable to a variety of iretwork topologies, inclnd- 
ing uni- and bi-directional chains, rings, and trees of processes. Unfold 
transformations in our system correspond to algorithmic model-checking 
steps, fold and goal replacement correspond to deductive steps, and all 
three types of transformations can be arbitrarily interleaved within a 
proof. Our framework thus provides a seamless integration of algorith- 
mic and deductive verification at hne levels of granularity. 



1 Introduction 

Advances in Logic Programming technology are beginning to influence the de- 
velopment of new tools and techniques for the specification and verification of 
concurrent systems. For example, constraint logic programming has been used 
for the analysis and verification of hybrid systems [Urb96] and more recently 
for model checking infinite-state systems [DP99]. Closer to home, we have used 
a tabled logic-programming system to develop XMC, an efficient and flexible 
model checker for finite-state systems [RRR’^97]. XMC is written in under 200 
lines of tabled Prolog code, which constitute a declarative specification of CCS 
and the modal mu-calculus at the level of semantic equations. Despite the high- 
level nature of XMC’s implementation, its performance is comparable to that 
of highly optimized model checkers such as Spin [Hol97] and Murtp [Dil96] on 
examples selected from the benchmark suite in the standard Spin distribution. 

* This work was partially supported by NSF grants CCR-9711386, CCR-9876242, 
CDA-9805735 and EIA-9705998. 
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More recently, we have been investigating how XMC’s model-checking ca- 
pabilities can be extended beyond finite-state systems. Essentially, this can be 
done by enhancing the underlying resolution strategy appropriately at the level of 
meta-programming, and without the undue performance penalties typically asso- 
ciated with the concept of meta-programming. In this sense, XMC can be viewed 
as a programmable verification engine. For example, we have shown in [DRS99] 
how an efficient model checker for real-time systems can be attained through the 
judicious use of a constraint package for the reals on top of tabled resolution. 

In this paper, we expand on this theme even further. In particular, we exam- 
ine how the tabled-resolution approach to model checking finite-state systems 
can be extended to the verification of parameterized systems. A parameterized 
system represents an infinite family of systems, each instance of which is finite 
state. For example, an n-bit shift register is a parameterized system, the param- 
eter in question being n. In general, the verification of parameterized systems 
lies beyond the reach of traditional model checkers and it is not at all trivial (or 
even possible) to adapt them to verify parameterized systems. 

The main idea underlying our approach is to reduce the problem of verify- 
ing parameterized systems to one of determining equivalence of goals in a logic 
program. We then establish goal equivalences by inducting on the size of proofs 
of ground instances of goals. To derive such induction proofs we were required 
to substantially generalize the well-established theory of logic program trans- 
formations encompassing unfold, fold and goal-replacement transformations. In 
particular, in a recent paper [RKRR99b] we developed a new transformation sys- 
tem that allows folding using multiple recursive clauses, which seems essential 
for proving properties of parameterized systems. 

In our framework, unfold transformations, which replace instances of clause 
left-hand sides with corresponding instances of clause right-hand sides, represent 
resolution. They thereby represent a form of algorithmic model checking; viz. the 
kind of algorithmic, on-the-fly model checking performed in XMC. Unfold trans- 
formations are used to evaluate away the base case and the finite portions of 
the induction step in an induction proof. Fold transformations, which replace 
instances of clause right-hand sides with corresponding instances of clause left- 
hand sides, and goal replacement transformations, which replace a goal in a 
clause right-hand side with a semantically equivalent goal, represent deductive 
reasoning. They are used to simplify a given program so that applications of the 
induction hypothesis in the induction proof can be recognized. 

Using our approach, we have been able to prove liveness and safety properties 
of a number of parameterized systems. Moreover, our approach does not seem 
limited to any particular kind of network topology, as the systems we considered 
have included uni- and bi-directional chains, rings, and trees of processes. The 
primary benefits can be summarized as follows. 

— Uniform framework. Our research has shown that finite-state systems, real- 
time systems, and, now, parameterized systems can be uniformly specified 
and verified in the tabled logic programming framework. 
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— Tighter integration of algorithmic and deductive model checking. Unfold, fold, 
and goal-replacement steps can be arbitrarily interleaved within the verifica- 
tion proof of a parameterized system. Thus our approach allows algorithmic 
model checking computation (unfold) to be integrated with deductive reason- 
ing (fold, goal replacement) at fine levels of granularity. Also, since deductive 
steps are applied lazily in our approach, finite-state model checking emerges 
as a special case of verifying parameterized systems. 

— High degree of automation. Although a fully automated solution to verifi- 
cation of parameterized systems is not possible, for many cases of practical 
interest, we have identified certain heuristics that can be applied to our proof 
system in order to completely automate the deduction involved. 

The idea of using logic program transformations for proving goal equivalences 
was first explored in [PP99] for logic program synthesis. Our work expands the 
existing body of work in logic program transformations with more powerful trans- 
formation rules and strategies that are central to verification of parameterized 
systems. Note that our transformation rules are also applicable for proving gen- 
eral program properties. 

Regarding related work in the verification area, a myriad of techniques have 
been proposed during the past decade for verifying parameterized systems, and 
the related problem of verifying infinite-state systems. [BCG89,EN95,ID99] re- 
duce the problem of verifying a parameterized system to the verification of an 
“equivalent” finite-state system. [WL89,KM95,LHR97] seek to identify a “net- 
work invariant” that is invariant with respect to the given notion of parallel com- 
position and stronger than the property to be established. The network-invariant 
approach is applicable to parameterized systems consisting of a number of copies 
of identical components (or components drawn from some finite set) that are 
composed in parallel. Another approach [CGJ95] aims to finitely represent the 
state space and transition relation of the entire family of finite-state systems 
comprising a given parameterized system, and has been used in [KMM+97] to 
extend symbolic model checking [McM93] to the verification of parameterized 
systems. This method requires the construction of a uniform representation for 
each class of networks, and the property in question must have a proof that is 
uniform across the family of networks. 

Perhaps the work most closely related to our own involves the use of the- 
orem provers for verifying parameterized systems. Rajan et al. [RSS95] have 
incorporated a mu-calculus model checker as a decision procedure within the 
PVS theorem prover [OSR92]. Inductive proofs can be established by the prover 
via calls to the model checker to verify finite subparts. Graf and Saidi [GS96] 
combine a custom-built specification/deduction system with PVS to formalize 
and verify invariant properties of infinite-state systems. 

The key difference between our approach and these is that we enhance model 
checking with deductive capabilities, rather than implement model checking as 
a decision procedure in a deductive system. In particular, the underlying eval- 
uation mechanism for model checking in XMG is essentially unfolding, and we 
have enhanced this mechanism with folding and goal-replacement transforma- 
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tions. In our approach, deductive steps are deployed only on demand and hence 
do not affect the efficacy of the algorithmic model-checking. More importantly 
our framework demonstrates that a tabled constraint logic-programming system 
can form the core of a verification engine that can be programmed to verify prop- 
erties of various flavors of concurrent systems including finite-state, real-time, 
and parameterized systems. 

2 Parameterized System Verification as Goal Equivalence 

In this section, we discuss how verification of temporal properties of parameter- 
ized systems can be reduced to checking equivalence of goals in a logic program. 



gen(X) , live(X) . 

X = [lU . 

transfX, Y) , live(Y) . 
System description Property description 

Fig. 1. Example: Liveness in a unidirectional token-passing chain 



gen( [1] ) . 
gen([0|X]) 
trans( [0, 1 |T] 
trans( [H|T] , 



gen(X) . 

, [I.OIT]) 
[HITI]) 



transCT, Tl) . 



thm(X) 

live(X) 

live(X) 



Modeling Parameterized Systems: Consider the parameterized system con- 
sisting of a chain of n token-passing processes. In the system’s initial state, the 
process in the right-most position of the chain has the token and no other process 
has a token. The system evolves by passing the token leftward. A logic program 
describing the system is given in Figure 1. The predicate gen generates the initial 
states of an n-process chain for all n. A global state is represented as an ordered 
list ( a list in Prolog-like notation is of the form [Head I Tail] ) of zeros and ones, 
each bit corresponding to a local state, and the head of the list corresponding 
to the local state of the left-most process in the chain. Each process in the chain 
is a two-state automaton: one with the token (an entry of 1 in the list) and the 
other without the token (an entry of 0). The set of bindings of variable S upon 
evaluation of the query gen(S) is { [1], [0,1], [0,0,1], .. . }. The predicate 
trans in the program encodes a single transition of the global automaton. The 
first clause in the definition of trans captures the transfer of the token from 
right to left; the second clause recursively searches the state representation until 
the first clause can be applied. 

Liveness Properties: The predicate live in Figure 1 encodes the temporal 
property we wish to verify: eventually the token reaches the left-most process. 
The first clause succeeds for global states where the token is already in the left- 
most process (a good state). The second (recursive) clause checks if a good state 
is reachable after a (finite) sequence of transitions. Thus, every member of the 
family satisfies the liveness property if and only if V X gen(X) live(X). More- 
over, this is the case if V X thm(X) gen(X) , i.e., if thm and gen are equivalent 
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(have the same least model). Clearly, testing the equivalence of these goals is 
infeasible since the minimal model of the logic program is infinite. However, we 
present in Section 3 a proof methodology, based on program transformations, 
for proving equivalences between such goals. 

Safety Properties: We can model safety properties by introducing negation 
into the above formulation for liveness properties, using the temporal-logic iden- 
tity G 4> = ~^F ->(/). Although our program transformation systems have been 
recently extended to handle programs with negation [RKRR99a], for simplicity 
of exposition we present here an alternative formulation without negation. In 
particular, we define a predicate bad to represent states that violate the safety 
property, show that the start states are not bad, and, finally, show that bad 
states are reachable only from other bad states. For instance, mutual exclusion 
in the n-process chain can be verified using the following program: 



bad is true if and only if the given global state has more than one local state 
with a token. Showing bad_start(X) false establishes that the start states 
do not violate the safety property. Showing that bad_src(X) bad_dest(X) 
establishes that states that violate the safety property can be reached only from 
other states that violate the property. These two facts together imply that no 
reachable state in the infinite family is bad and thus establish the safety property. 
A Note on the Model: XMC [RRR+97] provides a highly expressive process 
description language based on value-passing CCS [Mil89] for specifying parame- 
terized systems (although XMC is guaranteed to terminate only for finite-state 
systems). The above simplified presentation (which we will continue to use in 
the rest of this paper) is used to prevent a proliferation of syntax. 

3 Goal Equivalence Proofs Using Tableau 

In this section we describe the basic framework to construct such equivalence 
proofs. We begin by defining the relevant notations. 

Notations: We assume familiarity with the standard notions of terms, mod- 
els, substitutions, unification, and most general unifier {mgu) [Llo93]. A term 
having no variables is called a ground term. Atoms are terms with a predicate 
symbol at the root (true and false are special atoms), and goals are conjunc- 
tions of atoms. Atoms whose subterms are distinct variables (i.e., atoms of the 
form p{Xi, . . . ,Xn), where p is a predicate symbol of arity n) are called open 
atoms. We use the following notation (possibly with primes and subscripts) : p, q 
for predicate symbols; X, Y for variables; t, s for terms; X, Y for sequences of 
variables; t, s for sequences of terms; A, B for atoms; cr, 0 for substitutions; C, D 
for Horn clauses; a, (3 for goals; and P for a definite logic program, which is a 



bad([l|Xs]) one_more(Xs) . 

bad([_|Xs]) bad(Xs) . 



bad_start(X) gen(X) , bad(X) . 



one_more( [1 1 _] ) . 

one_more( [_|Xs] ) one_more(Xs) . 



bad_src(X,Y) trans(X, Y) , bad(X) . 
bad_dest(X,Y) trans(X, Y) , bad(Y) . 
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set of Horn clauses. A Horn clause C is written as A Hi, i? 2 , . . . , A, the 
consequent, is called the head of C and the antecedent Hi, H 2 , . . . , H„ the body 
of C. Note that we can write Horn clauses as A a. Semantics of a definite 
logic program P is given in terms of least Herbrand models, M{P). Given a goal 
a and a program H, SLD resolution is used to prove whether instances of a are 
in M(P). This proof is constructed recursively by replacing an atom H in a with 
f39 where B' [3 € P and 9 = mgu{B, B'). We use Hq, Hi, . . . ,Pn to denote a 
program transformation sequence where Pi+i is obtained from Pi by applying a 
transformation. We call Hq as the original program. 



3.1 Tableau Construction 

The goal equivalence problem is: given a logic program P and a pair of goals a, /3, 
determine if a and /3 are semantically equivalent in H: i.e., whether for all ground 
substitutions 9, a9 € M(P) 4^ /39 € M(P). This problem is undecidable in 
general and we attempt to provide a deductive system for identifying equivalence. 

We now develop a tableau-based proof system for establishing goal equiva- 
lence. Our proof system is analogous to SLD resolution. Let H = (Hq, Hi, ... , H^) 
be a sequence of logic programs such that Hj+i is obtained from Pj (1 < j < i) by 
the application of a rule in our tableau. Further let M{Pq) = M{Pi) = M{P 2 ) = 
. . . = M{Pi). An e-atom is of the form P \- a = P where a and P are goals, 
and represents our proof obligation: that a and P are semantically equivalent in 
any program in H. An e-goal is a (possibly empty) sequence of e-atoms (e-atoms 
and e-goals correspond to atoms and goals in standard resolution). 



(Ax) 


r h a = P 
hline 


where 


a = P 




(Tx) 


r h a = P 
r, Hi+i \- a = P 


where 


M{Pi+i) 


= M{Pi) 


(Gen) 


r h a = P 

hline H,Hi+i \~a = P, Po a' = P' 


where 


M{Pi+i) 


= M{Pi) if A 



Fig. 2. Rules for constructing equivalence tableau 



The three rules used to construct equivalence tableau are shown in Figure 2. 
The axiom elimination rule (Ax) is applicable whenever the equivalence of goals 
a and P can be established by some automatic mechanism, denoted by a = /3. 
Axiom elimination is akin to the treatment of facts in SLD resolution. The 
program transformation rule (Tx) attempts to simplify a program in order to 
expose the equivalence of goals. We use this rule when we apply a (semantics- 
preserving) transformation that does not add any equivalence proof obligations 
e.g. unfolding, folding. The sub- equivalence generation rule (Gen) replaces an 
e-atom with new e-atoms which are (hopefully) simpler to establish. This step 
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is akin to standard SLD resolution step. Note that the proof of o! = j3' may 
involve a transformation sequence different from, and not just an extension of, 
r. A successful tableau for an e-goal Eq is a finite sequence Eq^Ei,... ,E„ 
where ifi+i is obtained from Ei by applying Ax/Tx/Gen and En is empty. 

Theorem 1 Let Eq,Ei . . . ,En he a successful tableau, Pq be a (definite) logic 
program and Eq = (Pq) \~ a = p. For all ground substitutions 9, aO S M{Pq) 

PO S M(Pq), i.e. a. and P are equivalent in the least Herbrand model of Pq. 

The tableau, however, is not complete. There can be no such complete tableau 
(which can be proved using a reduction in [AK86]). 

Theorem 2 The problem of determining equivalence of predicates described by 
logic programs is not recursively enumerable. 

3.2 Program Transformations 

The Tx and Gen rules of our proof system require us to transform a pro- 
gram Pi into a program This is accomplished by applying logic program 

transformations that include unfolding, folding, goal replacement and definition 
introduction. 

For a simple illustration of program transformations, consider Figure 3. 
There, program Pi is derived from Pq by unfolding the occurrence of r in the 
definition of q. P 2 is derived from P\ by folding t , s in the definition of p using 
the definition of q. While unfolding is semantics preserving, indiscriminate fold- 



p 


: - t , s . 


P 


t , s 


• p q 


q 


s. 


q 


t , s . 


q t 


r 


: - t . 


r : - 


t . 


r t 



Program Pq Program Pi Program 



P 2 



Fig. 3. Example of an unfold/fold transformation sequence 



ing may introduce circularity, thereby removing finite proof paths, e.g. folding 
t , s in the definition of q in P 2 using the definition of p in Pq results in a program 
p :-q. q :~p. r :-t This removes p and q from the least model. 

We now present the program transformations informally. For a formal de- 
scription, the reader is referred to [RKRR99b]. With each clause C in program Pi 
of the transformation sequence, we associate a pair of integer counters that bound 
the size of a shortest proof of any ground atom A derived using C in program Pi 
relative to the size of a shortest proof of A in Pq . Thus the counters keep track 
of potential reductions in proof lengths. Conditions on counters are then used 
to determine if a given application of folding is semantics preserving. 
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(a) Unfolding (b) Folding 

Fig. 4. Schema for imfold/fold transformations 



Unfolding of an atom A in the body of a clause in Pi is shown in Figure 4a. 
The conditions for applying the transformation are : (i) . . . , An are the only 

clause heads in Pi which unify with A, and (ii) Uj is the mgu of A and Aj for all 
1 ^ J ^ Note that these conditions are taken directly from resolution, which 
means that unfolding is essentially a resolution step. 

Folding replaces an occurrence of the body of a clause with its head. The 
clause where the replacement takes place is called the folded clause and the 
clauses used to perform the replacement are called the folder clauses. The folding 
schema is illustrated in in Figure 4b, where the clauses of B are the folded clauses, 
and the clauses of A are the folder clauses. The folder clauses may come from 
some earlier program Pj{j < i) in the transformation sequence. The conditions 
for applying the transformation are^: (i) ai is an instance of a\ with substitution 
ai for all 1 < Z < n (ii) there is an atom A such that VI < Z < n Aiai = A and 
the folder clauses are the only clauses in Pj whose heads unify with A. 

Goal replacement replaces an atom B in a clause A a, Bf3 in program Pi 
with a semantically equivalent atom B' to obtain the clause A a, B' ,j3. Note 
that such a replacement can change lengths of proofs of A arbitrarily. To obtain 
the counters associated with the new clause we need to estimate the changes in 
proof lengths. In practice, we do so by using techniques based on Integer Linear 
Programming. Details appear in [Roy99]. 

Theorem 3 ([RKRR99b]) Let Pq,Pi,. . . , P/v be a sequence of definite logic 
programs where Pi+i is obtained from Pi by an application of unfolding, folding, 
or goal replacement. Then M{Pi) = M{Pq), 1 < i < N . 

Definition-introduction transformation adds clauses defining a new predicate to 
a program Pi. This transformation is used to generate “names” for goals. Note 

^ In addition, certain other conditions need to be imposed including conditions on the 
counters of the folder and folded clauses; we do not mention them here. 
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that after definition introduction, M{Pi+i) ^ M{Pi) since a new predicate is 
added to Pi+\. But for every predicate p in Pi, and all ground terms t, p(t) S 
M{Pi) p(i) G M{Pi+i). The tableau presented earlier can be readily extended 
to include such transformations. 

3.3 Checking Goal Equivalence from Syntax 

Recall that the axiom elimination rule (Ax) is applicable whenever we can me- 
chanically establish the equivalence of two goals. We now develop a syntax-based 
technique to establish the equivalence of two open atoms, i.e., atoms of the form 
p{X) and q{X). 

p(X) r(X). q(X) s(X). 

p(X) e(X,Y), p(Y) . q(X) e(X,Y), q(Y) . 

r(X) b(X) . s(X) b(X) . 

Consider the example program given above. We can infer that r(X) = s(X) 
since r and s have identical definitions. Then, we can infer q(X) = p(X), since 
their definitions are “isomorphic” . Formally: 

p 

Definition 1 (Syntactic Equivalence) A syntactic equivalence relation, 
is an equivalence relation on the set of predicates of a program P such that for 

p 

all predicates p,q in P, if p ^ q then: 

1. p and q have same arity, and 

2. Let the clauses defining p and q he {Ci,... ,Cm} and {Di, . . . ,D„}, re- 
spectively. Let ,C',^} and {D(,... ,D'^} he such that C[ (D[) is ob- 

tained by replacing every predicate symbol r in Ci (Di) by s, where s is the 

p 

name of the equivalence class of r (w.r.t. Then there exist two functions 
m} ^ {1, . . . , n} and (/ : {1, . . . , n} ^ {1, . . . , m} such that: 

(a) yi < i < m C'i is an instance of and 

(b) yi < j < n D'j is an instance of C'g^y. 

The largest syntactic equivalence relation can be computed by starting with all 
predicates in the same class, and repeatedly splitting the classes until a fixed 
point is reached. Syntactic equivalence is sound w.r.t. semantic equivalence, i.e. 

p 

Lemma 4 Let P he a program and ~ be the syntactic equivalence relation. For 
all predicates p, q, if p ~ q, then p{X) = q{X). 

4 Automated Construction of Equivalence Tableau 

We describe an algorithmic framework for creating strategies to automate the 
construction of the tableau. The objective is to: (a) find equivalence proofs that 
arise in verification with limited user intervention, and (b) apply deduction rules 
lazily, i.e. a proof using the strategy is equivalent to algorithmic verification for 
finite-state systems. 
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algorithm Prove{A, B: open atoms, _T:prog. seq.) 

begin 

let r = (Po, ... ,Pi) 

{* Ax rule *) 

if {A = p{X) A B = q{X) A p ~ g) then 
return true 

else nondeterministic choice 
(* Tx rule *) 

case FIN{{P, unfold{Pi)))-. (* Unfolding *) 
return Prove{A, B, {P, unfold (Pi))) 
case Folding is possible in Pi: 

return Prove{A, B , {P, fold{Pi))) 

(* Gen rule *) 

case Conditional folding is possible in Pi: 
let {A',B') — new.atom.equiv-forJold[Pi) 
return replace.and.prove{A, B, {A' , B'), P) 
case Conditional equivalence is possible in Pp. 
let {a, P) = new-goaLequw.for.equiv{A, B , Pi) 
return replace.andjprove{A, B, {a, j3), P) 
end choices 

end 

Fig. 5. Algorithmic framework for automated construction of tableau 



In our framework, the tableau rules and associated transformations are ap- 
plied in the following order. Given an e-atom F \- a = (3, the proof is complete 
whenever the axiom elimination rule (Ax) is applicable. Hence, we first choose 
to apply Ax. When the choice is between the Tx and Gen rules, we choose 
the former since Tx allows unfolding, i.e. resolution. This will ensure that our 
strategies will perform algorithmic verification, a’ la XMC, for finite-state sys- 
tems. For infinite-state systems, however, uncontrolled unfolding will diverge. 
To create finite unfolding sequences we impose the finiteness condition FIN in 
Definition 2. If FIN prohibits any further unfolding we either apply the folding 
transformation associated with Tx or use the Gen rule. Care must be taken, 
however, when Gen is chosen. Recall from the definition of Gen that a = (3 
in Pi+i implies a = (3 in Pi only if we can prove a new equivalence a' = f3' 
in Pq. Since Gen itself does not specify the goals in the new equivalence, its 
application is highly nondeterministic. We limit the nondeterminism by using 
Gen only to enable Ax or Tx rules. 

Definition 2 (Finiteness condition) An unfolding transformation sequence 
F = {Pq, ... , Pi, . . .) satisfies FIN (P) if and only if for the clause C and atom A 
selected for unfolding at Pi: (i) A is distinct modulo variable renaming from any 
atom B which was selected in unfolding some clause D S Pj{j < i) where C is 
obtained by repeated unfolding of D (ii) the term size of A is bounded a-priori 
by a constant. 



182 Abhik Roychoudhury et al. 



Hence, when no further unfoldings are possible, we apply any possible folding. 
If no foldings are enabled, we check if there are new atom equivalences that will 
enable a folding step. We call this a conditional folding step. Note that atom 
equivalences may be of the form p(t) = q(s), where t and s are sequences of 
arbitrary terms, whereas the test for syntactic equivalence is only done on open 
atoms. We therefore introduce new definitions to convert them into open atoms. 
Finally, we look for new goal equivalences, which, if valid, can lead to syntactic 
equivalence. This is called as a conditional equivalence step. In such a step, an 
equivalence proof on arbitrary goals is first converted into equivalence between 
open atoms by introducing new definitions. 

The above intuitions are formalized in Algorithm Prove (see Figure 5). Given 
a program transformation sequence P, and a pair of open atoms A, B, algorithm 
Prove attempts to prove that P \- A = B. Algorithm Prove uses the following 
functions. Function replace-and-prove constructs proofs for sub-equivalences cre- 
ated by applying the Gen rule. replace-and-prove{A, B, {a, (3), P) first introduces 
definitions for a and j3, then proves the equivalence (Pq) F a = /3 by invoking 
Prove, then replaces a hy (3 and finally invokes Prove to complete the proof 
of r \- A = B. Functions unfold{P) and fold{P) apply unfolding and folding 
transformations respectively to program P and return a new program. Whenever 
conditional folding is possible, the function new-atom_equiv-for^fold(P) finds the 
pair of atoms whose replacement is necessary to do the fold operation. Similarly, 
when conditional equivalence is possible, new-goaLequiv-for^equiv{A, B, P) finds 
a pair of goals a, (3 s.t. syntactic equivalence of A and B can be established after 
replacing a with (3 in P. 

Note that Prove terminates as long as the number of definitions introduced 
(i.e., new predicate symbols added) is finite. If multiple cases of the nonde- 
terministic choice are enabled, then Prove tries them in the order specified in 
Figure 5. If none of the cases apply, then evaluation fails, and backtracks to the 
most recent unexplored case. There may also be nondeterminism within a case; 
for instance, many fold transformations may be applicable at the same time. By 
providing selection functions to pick from the applicable transformations, one 
can implement concrete strategies from Prove. Details appear in [Roy99]. 



4.1 Example: Liveness Property in Chains 

Recall the logic program of Figure 1 which formulates a liveness property about 
token-passing chains, namely, that the token eventually reaches the left-most 
process in any arbitrary length chain. To establish the liveness property, we 
prove thm(X) = gen(X) by invoking Prove (thm(X) , gen(X), (Pq)). The proof tree 
is illustrated in Figure 6 (dashed arrows in the figure denote multiple applications 
of the transformation annotating the arrow). Prove first unfolds the clauses of 
thm to obtain: 



thm( [1] ) . 

thm([0|X]) gen(X), X = [1|_] . 

thm([0|X]) gen(X) , trans(X,Y), live([0|Y]). 
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Pq h thiti(X) =gen (X) 
; Unfolds 



p. 



Defn. Intro, (live' (Y) : - live ( [0 | Y] ) . 



Fold 




Goal Replacement 



PqK live' (Y) = live(Y) 

I Unfolds 



Pq,...,P^,Pj 2 I- thm(X) =gen(X) 



Fold 



P, 



10 



P, 



13 



Fold 



Fold 



p, 



11 



p, 



14 



live' - live 



thm ~ gen 



Fig. 6. Proof tree for liveness property in chains 



Since no unfolding or folding is applicable, conditional folding is done giving rise 
to the (sub)-equivalence live ( [0 I Y] ) = live (Y) . Since live ( [0 I Y] ) is not an 
open atom, a new definition live ’ (Y) : - live ( [0 1 Y] ) is added to P5 to yield 
Pq . Then Prove folds the third clause of thm using this definition and recursively 
invokes Prove{live’ (X),live(X), (Pq)) to establish live’ (X) = live(X). This 
subproof appears in the left branch of Figure 6. Finally, Prove replaces live ’ (X) 
with live(X) in the clauses of thm and completes the proof of thm(X) = gen(X) 
by applying two folding steps. 

It is interesting to observe in Figure 6 that the unfolding steps that transform 
Pq to P5 and P7 to Pio are interleaved with folding steps. This illustrates how 
we interleave algorithmic model-checking steps with deduction steps. 

4.2 Example: Mutual Exclusion in Token Rings 

Algorithm Prove generates a proof for mutual exclusion in a n-process token 
ring. The token ring is described by the following logic program: 

gen([0,l]). trans(XjY) transl(X,Y). 

gen([0|X]) gen(X) . trans ( [1 1 X] , [0 I Y] ) trans2(X,Y). 

transl ( [0, 1 1 T] , [1 ,0 I T] ) . trans2([0], [1]). 

transl([H|T] , [HITI]) transl (T,T1) . trans2( [H|X] , [H| Y] ) trans2(X,Y) . 

As in the case of chains (see Section 2 ), we represent the global state of a ring 
as a list of local states. Processes with tokens are in local state 1 while processes 
without tokens are in state 0. trans is now divided into two parts: transl which 
transfers the token to the left neighbor in the list, and trans2 which transfers the 
token form the front of the list to the back, thereby completing the ring. Mutual 
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Pq h bad src (X) = bad_dest (X) 

; Unfolds 



MO 

I Dejh. Intro, (si (X, Y) : - . . . ) 



h bad start (X) = fals 



Unfolds 



Defn. Intro. (s2 (X, Y) : - . . . ) 



bad start ~ false 



P^hsl (X,Y)= s2 (X,Y) 

Unfolds 



' - Defn. Introductions 



Rest of the proof 



^23 

si ~ s2 



Fig. 7. Proof trees for mutual exclusion in token rings 



exclusion, a safety property, is modeled using the predicates bad, bad_start, etc. 
as discussed in Section 2. These predicates, along with those listed above, form 
the initial program Pq. Recall that a safety proof can be completed by showing 
bad_start = false and bad_src = bad_dest. Figure 7 illustrates the proofs 
generated by Prove to demonstrate these equivalences. 

Invocation of Prowe(bad_start (X), false, (Pq)) performs unfoldings to ob- 
tain program P 3 where bad_start is defined using a single clause, namely: 
bad_start ( [0 I X] ) gen(X) , bad(X) . Prove now folds using the original 
definition of bad_start to obtain P 4 where bad_start is defined by the clause: 
bad_start ( [0 I X] ) :- bad_start (X) . Since bad_start is defined by a single 
self-recursive clause, it is detected as failed, and hence bad_start = false. 

An invocation of Prove (bad_src (X), bad_dest (X), (Pq)) performs unfoldings, 
to get program Pio where the definitions of bad_src and bad_dest are: 

bad.src([0,l,l|X] , [1,0, 1|X]). 

bad.src ( [0 , 1 ,H I T] , [1,0, H|T]) one_more(T) . 

bad.src ( [1 1 X] , [1 1 Y] ) transl(X,Y), one_more(X). 

bad.src([H|X] , [H|Y]) : - transl (X, Y) , bad(X) . 

bad.src([l,l|X] , [0,1|Y]) trans2(X,Y) . 

bad.src ( [1 ,H I X] , [0,H I Y] ) trans2(X,Y) , one_more(X) . 

bad.dest([0,l,l|X] , [1,0,1|X]). 

bad.dest ( [0, 1 ,H I T] , [1,0,H|T]) one_more(T) . 

bad.dest ( [1 1 X] , [1 1 Y] ) transl (X,Y) , one_more(Y) . 

bad.destC [H|X] , [H|Y] ) transl (X,Y) , bad(Y) . 

bad.dest ( [1 , 1 1 X] , [0 , 1 1 Y] ) trans2(X,Y), onejnore (Y) . 

bad.destC [1,H|X] , [0, HI Y] ) trans2(X,Y) , bad(Y) . 
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Now, to show bad_src = bad_dest, Prove applies conditional equivalence 
steps, generating the following (sub)-equivalences: 
transl(X,Y), onejnore(X) = transl(X,Y) , one_more(Y) 
transl(X,Y), bad(X) = transl (X,Y) , bad(Y) 
trans2(X,Y), onejnore(Y) =trans2(X,Y) 
trans2(X,Y), onejnore(X) = trans2(X,Y) , bad(Y) 

We now show the proof of the first of the above. Proofs of the other three 
(sub)-equivalences proceed similarly, and are omitted. Since the goals are not 
open atoms, the following definitions are created to obtain program P\2. 

sl(X, Y) transl(X,Y), onejnore (X) . 

s2(X, Y) transKXjY), onejnore (Y) . 

Since no new unfolding is applicable at P12, the clauses of bad_src and bad_dest 
are folded using the above two clauses to obtain P14. Prowe(sl (X) , s2 (X) , (Pq)) 
is then invoked by Prove as a subproof. This subproof is completed after a 
sequence of unfoldings (to reach program P21) and two foldings, yielding P23: 

sl([0,l|X], [1,0|X]). s2([0,l|X], [1,0|X]). 

sl([l|X] . [1|Y]) transl(X,Y) . s2( [1 1 X] , [1 1 Y] ) transl (X,Y) . 

sl([H|X] , [HIY]) sl(X,Y). s2( [H I X] , [H I Y] ) :-s2(X,Y). 

si s2 and hence sl(X) = s2(X). 

5 Concluding Remarks 

A preliminary prototype implementation of our transformation system, built on 
top of our XSB tabled logic-programming system [XSB99], has been completed. 
So far we have been able to automatically verify a number of examples including 
the ones described in this paper. Our plan now is to investigate the scalability 
of our system on more complex problems such as parameterized versions of the 
Rether protocol [DSC99] and the Java meta-locking protocol [BSWOO]. 
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Abstract. We present a method that allows to verify parameterized 
networks of finite state processes. Our method is based on three main 
ideas. The first one consists in modeling an infinite family of networks by 
a single WSIS transition system, that is, a transition system whose vari- 
ables are set (2nd-order) variables and whose transitions are described in 
WSIS. Then, we present methods that allow to abstract a WSIS system 
iirto a finite state system that can be model-checked. Finally, in order 
to verify liveness properties, we present an algorithm that allows to en- 
rich the abstract system with strong fairness conditions while preserving 
safety of the abstraction. We implemented our method in a tool, called 
PAX, and applied it to several examples. 



1 Introduction 

Recently there has been much interest in the automatic and semi-automatic 
verification of parameterized networks, i.e., verification of a family of systems 
{Vi I i € uj}, where each Vi is a network consisting of i finite-state processes. 
Apt and Kozen show in [AK86] that the verification of parameterized networks 
is undecidable. Nevertheless, automated and semi-automated methods for the 
verification of restricted classes of parameterized networks have been developed. 
The methods presented in [GS92,EN95,EN96] show that for classes of ring net- 
works of arbitrary size and client-server systems, there exists k such that the 
verification of the parameterized network can be reduced to the 
verification of networks of size up to k. Alternative methods presented in 
[KM89,WL89,BCG89,SG89,HLR92,LHR97] are based on induction on the num- 
ber of processes. These methods require finding a network invariant that ab- 
stracts any arbitrary number of processes with respect to a pre-order that pre- 
serves the property to be verified. While this method has been originally pre- 
sented for linear networks, it has been generalized in [GGJ95] to networks gen- 
erated by context-free grammars. In [GGJ95], abstract transition systems were 

* This work has been partially supported by the Esprit-LTR project Vires. 
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used to specify the invariant. An abstract transition system consists of abstract 
states specified by regular expressions and transitions between abstract states. 
The idea of representing sets of states of parameterized networks by regular 
languages is applied in [KMM+97], where additionally finite-state transducers 
are used to compute predecessors. These ideas are applied to linear networks as 
well as to processes arranged in a tree architecture and semi-automatic symbolic 
backward analysis methods for solving the reachability problem are given. The 
work presented in [ABJN99] extends the ideas in [KMM+97] by considering the 
effect of applying infinitely often a transition that satisfies certain restrictions. 
These restrictions allow to characterize the effect of the repeated application 
of the transition by finite-state transducers. Moreover, the method presented 
in [ABJN99] allows to consider networks of processes guarded by both local and 
global conditions that restrict the context in which a transition can be taken. 
Global conditions are typically used in many mutual exclusion algorithms such 
as Szymanski’s algorithm, the bakery and ticket algorithms by Lamport and 
Dijkstra’s algorithm. 

In this paper we present a method for the verification of parameterized net- 
works that can deal with a larger class of networks than the methods presented 
in [KMM+97,ABJN99] and that is applicable to verify communal liveness (also 
referred to as weak liveness) properties [MP94]. 

To verify parameterized protocols we first transform a given infinite family of 
networks of finite processes into a bisimilar single transition system whose vari- 
ables are set variables and whose transitions are described in WSIS, the weak 
monadic second order logic of one successor. We call such systems WSIS tran- 
sition systems. Then, we abstract the obtained WSIS transition system into a 
finite abstract system that can be analyzed using model-checking techniques. To 
obtain such a finite abstraction, one needs to come up with an appropriate ab- 
straction relation and to construct a eorreet abstract system, i.e., a system which 
exhibits for every behavior of the WSIS system a corresponding abstract behav- 
ior. We present a method to construct an abstraction relation from the given 
WSIS transition system and three techniques that allow to automatically con- 
struct either a correct abstract system, the reachability state graph of a correct 
abstract system without constructing the system itself or, finally, an abstraction 
of such a graph. Our experience shows that our method for constructing an ab- 
straction relation is useful for many examples and that it is useful to have the 
three techniques for constructing an abstract system. 

It is well known that an obstacle to the verification of liveness properties us- 
ing abstraction, e.g. [CGL94,LGS'*’95,DGG94], is that often the abstract system 
contains cycles that do not correspond to paths in the concrete system. This 
is not surprising since the main goal of an abstraction relation is to identify 
and merge states together, which consequently introduces new cycles. A way to 
overcome this difficulty is to enrich the abstract system with fairness conditions 
or more generally ranking functions over well-founded sets that eliminate unde- 
sirable cycles, that is, cycles that do not correspond to concrete computations. 
The main problem is, however, to find such fairness conditions. To tackle this 
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problem, we present an algorithm that given a reachability state graph of an 
abstraction of a WSIS system enriches the graph with strong fairness conditions 
while preserving the property that to each concrete computation corresponds an 
abstract fair one. Hence, we can use the enriched graph to prove liveness prop- 
erties of the WSIS systems, and consequently, of the parameterized network. 

We implemented our method in a tool, we call pax, that uses the decision 
procedures of Mona [KM98,H,J,J+96] to check the satisfiability of WSIS for- 
mulas. We then applied our method to several examples including Szymanski’s 
mutual exclusion algorithm, a server-ring as well as a token passing protocol. 
The first results obtained using our method and pax are very encouraging. 



2 Preliminaries 

In this, section, we briefly recall the definition of weak second order theory of 
one successor (WSIS for short) [Biic60,Tho90] and introduce the logic we use to 
describe the class of parameterized systems we are interested in. 

Terms of WSIS are built up from the constant 0 and Ist-order variables by 
applying the successor function succ(t) (“t -|- 1”). Atomic formulae are of the 
form b, t = t' , t < t' , t G X, where 6 is a boolean variable, t and t' are terms, 
and X is a set variable (2nd-order variable). WSlS-formulae are built up from 
atomic formulae by applying the boolean connectives as well as quantification 
over both Ist-order and 2nd-order variables. First-order monadic formulae are 
WSlS-formulae in which no 2nd-order variables occur. 

WSlS-formulae are interpreted in models that assign finite subsets of w to 
2nd-order variables and elements of w to Ist-order variables. The interpretation 
is defined in the usual way. 

Given a WSIS formula /, we denote by |/] the set of models of /. The set of 
free variables in / is denoted by free{f). We say that / is (Ist-order) closed, if it 
does not contain (Ist-order) free variables. In addition to the usual abbreviations, 
given a 2nd-order variable P, we write Wpiif instead oi Wi : i G P f and 
3pi'.f instead of 3i:i G P A f . 

Finally, we recall that by Biichi [BiicfiO] and Elgot [Elg61] the satisfiability 
problem for WSIS is decidable. Indeed, the set of all models of a WSlS-formula 
is representable by a finite automaton (see, e.g., [Tho90]). 

Let u be a variable. To define parameterized systems, we introduce the set 
AF (u) of formulae / defined by: 

/ ::= b[x] I I / A/ I V„a;:/ | 3nX:f , 

where x is a position variable, 6 is a boolean array variable. Let m G to. We denote 
by Em the set of evaluations s such that s(n) = m, s(x) G {0, • • • , m — 1} and 
s{b) : {0, • • • ,m — 1} — s- {true, false}. Then, formulae in AF(n) are interpreted 
over evaluations s G UmGw usual way. In the sequel, we also assume 

the usual notion of free variables, closed formulae, etc., as known. 
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3 Parameterized Systems 

We now introduce a class of parameterized systems for which we develop an 
abstraction-based verification technique. 

Definition 1 (Boolean Transition Systems). A boolean transition system 
S{i,n), parameterized by n and i, where n and i are variables ranging over 
natural numbers, is described by the triple (V,0,T), where 

— V = {6i, . . . , &fc} and each bj, 1 < j < k, is a boolean array of length n. 

— 0 is a formula in AF(n) with free{0) C V U {i} and which describes the set 
of initial states. 

— T is a finite set of transitions where each t G T is given by a formula 
Pr G AF(n) such that free(pr) C V U W U {z} and 

We denote by Vm the parallel composition S {I, m), where S{l,m) is 
obtained from S{i,n) by substituting m for n and I for i and where || de- 
notes the interleaving-based parallel composition (asynchronous product). No- 
tice, that if we identify the boolean array variables bj by the m boolean vari- 
ables bj [1] , • • • , bj [m] , the formulae describing the initial states as well as the 
transitions of ||™o^S'(Z,m) are first-order WSIS formulae whose free variables 
are in V, respectively, VU V'. Thus, Vm is a transition system in the usual sense, 
i.e., it does not contain the parameters n and i. Hence, we assume the definition 
of a computation of Vm as known and we denote by \Pm\ the set of its compu- 
tations. Then, a monadic parameterized system V (MPS for short) built from 
S{i,n) is the set {Vm | m > 1}. 

To illustrate the above definitions we consider Szymanski’s mutual exclusion 
algorithm [Szy88] as a boolean transition system. 

Example 1 (Szymanski’s mutual exclusion algorithm). Consider the following 
version of Szymanski’s mutual exclusion algorithm (cf. [ABJN99]), where each 
process S{i,n) is described as follows: 

await V„ j : V V at_^ 4 [j] 

(. 2 - skip 

4: if j : at J 2 [j] V at .4[j] V at_4[j] V atJ 7 [j] 
then goto 4 
else goto 

4: await j : V at_4[j] V &tlr[j] 

4: await V„ j : at4i|j] V at_4[j] V at^slj] V at_4[j] V a,t2-j[j] 

4: await \/n j ■ j < i ^ (at4i[j] V at_4[j] V at_4[j]) 
fy: ( critical section ); goto £i 

For the sake of presentation, the example is given in the style of [MP95]. The 
await statements express the guards for the transitions leading from one control 
location to the next one, i.e., the processes have to wait until the guard becomes 
true. In our formal model the control locations are modeled by a boolean array 
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variable at_£fc for each location 1 < fc < 7. According to Definition 3 the 
transition from i\ to £2 is given by the AF(n) formula: 

(V„ j : at Ji[j] V atJ 2 [j] V at AL i at-A[j] ^ atJ;[j] 

A at_^i [i] A ^at_A [*] A at _^2 [*] ^ A[=s at-£/ [*] ^ at_£j [i] . 

The initial condition states that each process starts in 

Our aim is to prove that this algorithm satisfies the mutual exclusion prop- 
erty, which can be expressed by at_^ 7 [i] A at.-^ 7 [j]. o 

4 WSIS Transition Systems 

In this section, we introduce WSIS transition systems which are transition sys- 
tems with variables ranging over finite sub-sets of uj and show how they can be 
used to represent infinite families of boolean transition systems. 

Definition 2 (WSIS Transition Systems). A WSIS transition system S = 
(V,0,T) is given by the following components: 

— V = {X \, . . . , Xk\: A finite set of second order variables where each variable 
is interpreted as a finite set of natural numbers. 

— 0: A WSIS formula with freeiO) C V describing the initial condition of the 
system. 

— T: A finite set of transitions where each t G T is represented as a WSIS 

formula Pr(V, V'), i.e., free{pr) C V U V'. □ 

The computations of S are defined as usual. Moreover, let |5] denote the set of 
computations of S. 

Relating parameterized and WSIS transition systems. We define a translation 
that maps an MPS to a bisimilar WSIS system. 

We fix a 2nd-order variable P that is used to model the set of indices of the 
processes up to n. The translation from MPS to WSIS systems uses a function 
tr from AF(n) into WSIS. This function replaces in an AF (n)-formula all occur- 
rences of atomic sub-formulae of the form 6[z] hy i G B, all n by max(P) -|- 1^, 
and A„ by Xp where A is one of the quantifiers V or 3. 

Definition 3 (Translation of Boolean to WSIS Systems). Consider an 
MPS system V built from S{i,n) where S{i,n) = (V,0,T). Define a WSIS 
system (V,0,'T) by constructing the variable set, the initial condition, and the 
transitions as follows: 

— For each boolean array bk in V , V contains the variable B^. Additionally, V 
contains the set variable P. 

— Let 0 be 3n : P = {0, . . . , n — 1} A Uf=i Bi C P A (ff pi : tr{0)). 

— Let T be the set {3pi : tr{pr) A P = P' A (J/Li B'^ <Z P' \ t G T}. 

^ It is not difficult to check that max(P) can be expressed in WSIS. 
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We denote the above transformation of an MPS system V by Tr(fP). □ 

Example 2 (Szymanski cont’d). The translation of Example 1 into a WSIS sys- 
tem introduces a set variable P and set variables At_£i, . . . , At.^y. According to 
the above definition of the translation we have as initial condition 0 

k 7 

3n : P = {0, . . . , n — 1} /\ \^ Bi C P A\/ p i : {i G At_£i A l\^i ^ At-ii) . 

1=1 1=2 

The translation of the AF(n) formula characterizing the transition from £i to £2 
presented in Example 1 yields 

(Vp j '■ j G At_£i U At-^2 U At_£4) A Vp j : j ^ i A[=i J G At.^/ ^ j G At_£j 
A i G AtJi A i ^ At J'l A i G AtJ '2 A ALs * ^ ^ ^ 

which, using the invariant Bi C P, can be simplified to 

(Vp j : j e At Ji U At J 2 U At J 4 ) A ALs = AtJ( 

A At_A = Atj£i \ {i} A At_^2 = At_£2 U {f} . 



o 

In order to state the relationship between an MPS V and its translation, we 
introduce a function h relating the states of both systems. Let V be an MPS 
built from S{i, n) = (F, 6*, T) with V = {bi, . . . , b^}. Let m be a natural number. 
Let E denote the set of interpretations s of F such that s(A) C s(P), for 
each X G V. Then, define ■ Em — *■ A, s 1 -^ s by s{P) = {0, ...,m — 1} 

and s{Bj) = {I < m \ s{bj[l]) = true}, for every 1 < j < fc. Then, we define 
h = Umsoj Notice that h is a bijection. 

The following lemma shows that h is consistent with the translation tr from 
AF(n) into WSIS. 

Lemma 1. Let f be a formula in AF(n) with free{f) C F U F' U {ij and let all 
m G OJ, for all s, s' G Em, we have: 

(s,s')h/ 'iff iHs),Hs')) \= tr{f) . 



□ 

Using this lemma we can prove the following theorem that justifies our veri- 
fication method given in Section 5. The theorem states that Vm is bisimilar to 
Tr{V) when we initialize P to {0, . . . , m — 1}. 

Theorem 1 (Relating Boolean and WSIS Systems). Let V be an MPS 

built from S{i,n) and mG uj. Then, h is a bisimulation between Vm o,nd Tr*(fP), 
where Tr*(fP) is obtained from Tr(fP) by taking as initial condition 0 = P = 
{0, . . . , m — 1} A Uz=i C P A Vp i : tr{0). 
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Proof: Consider sq to be an initial state of Vm, i-e., sq |= O. With Lemma 1 it 
follows that 



k 

h{so) ^ P = {0, . . . , m - 1} A [J C P A (Vpz : tr{0)) . 

1^1 

Vice versa, for any initial state So of some computation in |7r*(P)] the 

state h~^(So) is an initial state of P. 

With the same argumentation we can show for s, s' G Em and s,S'gE with 

s = h{s) that for any t G T, 

— if s' is a T-successor of s then h{s') is a tr(p,-)-successor of s, and 

— if s' is an tr(p,-)-successor of s then h~^{s') is a r-successor of s. 

Hence, both systems are bisimilar. □ 

Using Theorem 1, we can prove the following: 

Corollary 1. Let V he an MPS built from S{i,n). Then, lifting h to computa- 
tions, we have a bijection between UmGwI^™! 

5 Abstracting WSIS Systems 

In Section 4, we have shown how parameterized boolean transition systems can 
be translated into WSIS systems. This translation allows us to consider a single, 
though infinite-state, transition system instead of an infinite family of systems. 
In the following, we present a method to construct finite abstractions of WSIS 
systems. 

To do so, we first present a heuristic that allows to construct for a given WSIS 
system an abstraction function such that the corresponding abstract system has 
a finite state space. Then, we present a method that, given such a function, 
constructs a finite transition system that is an abstraction of the given WSIS 
system. Model-checking techniques can then be used to construct a state graph 
of this abstract system. 

The nodes of the constructed graph represent sets of abstract states and the 
edges correspond to abstract transitions. This graph contains all reachable ab- 
stract states. The nodes of the finest graph that can be constructed represent 
singleton sets, i.e., single abstract states. The coarsest graph has one node corre- 
sponding to the set of reachable states. In fact, the granularity of the computed 
graph depends on the techniques used during exploration. 

While the previous method first constructs an abstract system from which a 
graph is computed, we also present two methods inspired by [GS97] for comput- 
ing an abstract state graph, resp. an abstraction of it, without computing the 
abstract transition system at all. These methods are useful in case the abstract 
system is not computable for size reasons. 

Finally, we describe our pax tool which implements these techniques using 
Mona [KM98,HJJ+96]. 



Abstracting WSIS Systems to Verify Parameterized Networks 195 



We first recall some definitions and the idea of proving properties of systems 
by abstraction. 

Given a transition system S = (V,6*,T) and a total abstraction relation 
a C E X Ea, we say that Sa = {VatOaiTa) is an abstraction of S w.r.t. a, 
denoted by S Sa, if the following conditions are satisfied: 

— So H ® implies a(so) H 

— T O a~^ ^ C(~^ O TA- 

Let □(/?, ^ipA be invariance formulae, i.e., ip, pA are state formulae. Then, from 
S Ea Sa, q;“^(|:^a]) E |<p], and Sa H ^“^a we can conclude S ^ Up. 
This statement, which is called preservation result, shows the interest of ver- 
ification by abstraction: since if 5 a is finite, it can automatically be checked 
whether 5 a ^ Up a- In fact a similar preservation result holds for any tem- 
poral logic without existential quantification over paths, e.g., WCTL*, LTL, or 
Pa [CGL94,DGG94,LGS+95]. 

5.1 Constructing the Abstraction Function 

Our heuristic to construct an abstraction function for WSIS systems assumes 
the transitions to have the following form: 

3pi : G A L(i) A C{i) AV' = exp(V, V^) , 

where G, L{i),C{i) are WSIS formulae whose free variables are in V and such 
that: 

— G is a Ist-order closed WSIS formula. Intuitively, G describes a global con- 
dition. E.g., in the Szymanski example (see Example 2), the presented tran- 
sition contains the global condition Vp j : j e At_£i U At _£2 U At_^ 4 . 

— L{i) is a quantifier-free formula with i as the unique free Ist-order variable. 
Intuitively, if i models a process index then L{i) is a condition on the local 
state of this process. 

— C{i) is a condition that as in the case of L{i) has i as the unique free Ist- 
order variable but which contains Ist-order quantifiers. Intuitively, it imposes 
conditions on the context of process i. 

Though, the above requirements restrict the set of considered WSIS systems, it 
still includes all translations of MPS systems. 

Let 5 = (V, 0, T) be a WSIS system whose transitions satisfy the restriction 
above. 

We are now prepared to present our heuristic for constructing abstraction 
functions. The set Va of abstract variables contains a boolean variable bx for 
each variable A G V. Moreover, for each global guard G, resp. local guard L 
occurring in a transition, it contains a boolean variable bo, resp. bp. Since the 
context guards G(i) describe a dependence between process i and the remaining 
processes, it turns out to be useful to combine them with the local guards. In- 
deed, this allows to check, for instance, whether some dependence is propagated 
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over some transitions. Therefore, we introduce boolean variables for some 

boolean combinations of local guards and context guards. Additionally, Va con- 
tains a boolean variable for each state formula appearing in the property to be 
verified. 

It remains now to present how we relate the concrete and abstract states, 
i.e., to describe an abstraction relation a. The abstraction relation a can be 
expressed on the syntactic level by a predicate a over V, Va which is defined as 
the conjunction of the following equivalences: 



bx = X ^ % 
ba = G 

6l = 3p f : L{i) 
bLk,Ci = 3p i : Lk{i) A Ci{i) 

Henceforth, we use S(V', V^) to denote the predicate obtained from a by sub- 
stituting the unprimed variables with their primed versions. 

Example 3 (Szymanski cant’d). Applying the above heuristic on Szymanski’s 
algorithm (see Example 2) we get seven boolean variables: 

tjji = AtJi ^ 0, for each 1 < i < 7 . 

The global guards not referring to i can be derived by the above variables and 
do not lead to a finer partitioning of the state space. All the local guards i G 
At-ii would introduce a boolean variable with meaning Bi : i G At-ii which is 
equivalent to stating that At_£/ is not empty. In the transition leading from £q to 
It we have a context Vj < i : j G At_£i U At _£2 U At _£4 which we have to combine 
with the local guards i G At-£i. For this example it turns out to be enough to 
take only one combination, namely 

(fi = 3i : i G At-£r AVj<i:jG At_£i U At_£2 U At_t'4 . 

Moreover, for the property of interest we introduce 

^ = —<31,) : I ^ j A I G At_£^ A j G At-£y . 



o 



5.2 Constructing the Abstract System 

In Section 5.1, we presented a method that allows to construct an abstraction 
function from a given WSIS system. In this section, we show how to use this 
abstraction function to automatically construct a finite transition system that 
can be model-checked. 

Let S = (V, 0, T) be a given WSIS system that satisfies the restriction given 
in Section 5.1 and let a be the abstraction function constructed by the method 
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given in the same section. Notice that since the abstract variables are booleans, 
the abstract system we construct is finite, and hence, can be subject to model- 
checking techniques. Moreover, we make use of the fact that both S(V, Va) and 
the transitions in T are expressed in WSIS to give an effective construction of 
the abstract system. 

Henceforth, given a set 7 of abstract states, we denote by 7 (Va) a WSIS 
formula that characterizes this set. 

The abstract system we construct contains for each concrete transition t an 
abstract transition ta, which is characterized by the formula 

3V, V' : S(V, Va) a Pr{V, V') A a(V', V'a) 

with free variables Va and V'a- 

The initial states of the abstract system we construct can be described by 
the formula 

3V:S(V,Va) . 

To compute them, one has to find all states fulfilling this formula, which is 
possible since this is a WSIS formula. 



5.3 Constructing Abstract State Graphs 

We first define state graphs of transition systems. Note that there is a whole set 
of state graphs for a given transition system. 

Definition 4 (State Graphs). Let S = (V, 6 *,T) he a transition system and 
S he the set of all reachable states of S. A state graph Q of S is a tuple 
{N ,£,No, p), where N is a set of nodes, JVq C JV is the set of initial nodes, 
£ C JV X T X JV is a set of labeled edges, and /r : Af — *■ 2^ is a labeling function, 
such that the following conditions are satisfied: 

[01 C 

2. Vq G JV,T G T : post^{p{q)) C U(q t (j')Gf POst^{p{q)) is the set 

of successors of p{q) w.r.t. t. □ 

There are several strategies to calculate a state graph for an abstract system. 
First of all, if one has previously computed the abstract system as explained in 
Section 5.2, one can use model-checking techniques, for example a forward state 
exploration, to construct a state graph. The actual graph obtained depends on 
the computation techniques used. 

Another way is to compute such a graph without calculating the abstract 
system at all. The nodes of the graph are sets of abstract states. One starts 
with an initial node representing the set of abstract initial states, which are 
computed as shown in Section 5.2. Assume that a concrete transition r and 
node q are given. The formula 



3Va, V, V' : p{q){VA) A 3(V, Va) A p,(V, V') A a(V' , V'a) 
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describes the set M of abstract post states w.r.t. ta- Then, a node q' with 
= M and an edge {q, ta, q') are added to the graph. This process is repeated 
until no new nodes or edges can be added. The so obtained graph is a state graph 
of Sa, we call this calculation precise computation. 

Since we restrict ourselves to abstraction functions of the form 

S(V,Va)= f\ ai^ifi{V) , 

l<i<k 

where Va = {o-i, ■ ■ ■ , cik}, we can also eliminate the abstract variables Va by 
replacing each abstract variable by ipi(V). 

The decision procedure for WSIS is based on constructing a finite automaton 
over finite words that recognizes the set of models of the considered formula. In 
practice, however, it can happen that the automaton cannot be constructed 
because of its size. In this case, we propose to go on as follows to obtain an 
abstract state graph of Sa- 

We start with the same initial node as before. Given a node q and concrete 
transition r, we construct new nodes by computing for each abstract variable 
the set Mi C {true, false} of fulfilling values for a' of 

3Va, V, V' : m^)(Va) A S(V, Va) A p.(V, V') A (o' ^ . 

Again, the abstract variables Va can be eliminated. In case Mi is empty for 
some i, then there does not exist any post state, and hence, the computation 
for the other variables can be omitted. Otherwise, instead of taking a node 
representing the set of abstract post states, one takes a new node q' with p{q') = 
|s I Vi : s{ai) G Mi} and a new edge {q, ta, q')- The set p{q') contains at least all 
possible abstract post states w.r.t. ta- It is not difficult to see that this method 
computes an abstraction of Sa, and hence, is also an abstraction of S- 



5.4 The Pax Tool 

We use Mona [KM98,HJJ+96] to decide the predicates mentioned above. In 
fact, Mona is able to construct all models of a WSIS predicate. 

Our system pax constructs state graphs. It uses Mona to compute the ab- 
stract initial states, the abstract transitions, or the set of abstract post states 
represented by a state graph node. To do so, it creates from its input files input 
for Mona and interprets the Mona results. Once an abstract system (resp. ab- 
stract state graph) is constructed, a translation to SMV, alternatively to SPIN, 
can be used to model-check the obtained abstract system (resp. abstract state 
graph). 

PAX allows the combination of the method of Section 5.2, which consists 
in computing abstractions of concrete transitions independently of any source 
abstract state, with the methods of Section 5.3. This is helpful in case Mona does 
not succeed in computing an abstract transition because of memory limitations. 

In Table 1 we give run time results for the calculation of the abstract systems 
of some examples, one of it is the Szymanski mutual exclusion algorithm given 
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in Example 3. The construction of the state graph from the abstract system does 
not require mentionable time. We used a Sun Ultra Sparc 5/10 with 768 MB of 
memory and 333 MHz processor. 



Table 1. PAX construction of abstract transition systems 



Example 


Abstract Transitions System 


Szymanski 


7 min 28 sec 


Server-ring 


40 sec 


Token passing 


5 sec 



The run time results for the construction of a state graph (resp. an abstrac- 
tion) without previous computation of the abstract system of these examples is 
summarized in Table 2. 



Table 2. PAX results for state graph construction 



Example 


Precise Computation 


Abstraction 


Szymanski 


49 min 52 sec 


56 sec 


Server-ring 


1 min 5 sec 


13 sec 


Token passing 


1 min 40 sec 


19 sec 



Example 4 (Szymanski cant’d). For the Szymanski’s algorithm and the abstrac- 
tion function given in Example 3, we obtain using the last method of Section 5.3 
the state graph presented in Figure 1. The labeling function p is also given in 
Figure 1 in form of the predicates p{q) for each node q. The initial states are 
marked by an edge without source node. It is not difficult to check that no state 
falsifying the mutual exclusion property is reachable in the obtained graph, o 

6 Proving Liveness Properties 

Let 5 be a WSIS transition system and G = (Af, A/ q, m) be a state graph of 
Sa constructed from S and an abstraction function a. Let (p be an LTL formula. 
Let ^ 1 , • • • , be the atomic subformulae of p such that, for every node p G G, 
either all states in p{p) satisfy or none does, i.e., we have either p{p) 
or p{p) is valid. For each we introduce a proposition Pi. Then, let 

G = (Af, f , A/q, jz) be a Kripke structure with the same nodes, edges, and initial 
nodes as G and such that Pi € u(p) iff p{p) ^i is valid. Let also p be the 
formula obtained from p by substituting Pi for ^i. Then, S \= p., li G \= p. 

Example 5 (Szymanski cant’d). Let G = (JV,£,JVq, p) be the state graph for 
Szymanski’s algorithm given in Example 4. Let us now consider the liveness 
property p = expressing that the critical section is entered infinitely 
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4—5 



Fig. 1. Reachability graph for Szymanski’s mutual exclusion algorithm 



often. Clearly, we can define a Kripke structure Q = {Af,£,Afo,iy) with the 
same nodes and edges as Q and with a proposition P such that P G v{p) iff 
\= fi{p) — > ipT- Thus, all nodes labeled by P are shadowed in Figure 1. Moreover, 
we get (p = OOP. o 

It is easy to see that (p does not hold in the Kripke structure Q. This is due to 
the cycles which generate infinite traces in Q without ever reaching a shadowed 
node. However, these traces have no corresponding computations in the concrete 
WSIS system. E.g., the loops labeled 1 — > 2 are the abstraction of the transition 
taking an element out of At_£i and adding it to At_.^ 2 - Clearly, since WSIS is 
interpreted over finite sets, it is impossible to infinitely execute transition 1^2 
without taking a transition that adds elements to At_^i. 

In this section we present a method that allows us to add fairness conditions 
to the Kripke structure Q constructing a fair Kripke structure such that we 
still have 5 |= <^, if ^ <p and such that the added fairness conditions rule out 
infinite traces in Q that have no counter-parts in S. 

The method uses a marking algorithm that labels each edge of the considered 
state graph with one of the symbols {+x,~x,=x} for each set variable X of 
the original WSIS system. Intuitively, the labels —x resp. =x express whether 
the transitions at the concrete level reduce resp. maintain the cardinality of a 
set X, the label +x represents all other cases. 

For the sake of presentation, we use p{Va) instead of p{p). 
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Marking Algorithm 

Input: WSIS system S = (V,0,T), abstraction relation a, state graph 
g = ofSA 

Output: Edge labeling of G 

Description: For each X G V, for each edge e = {p, ta, q) € £, let r be the 
concrete transition in T corresponding to ta- Moreover, let A{X,e,-<), 
with {C,=}, denote the WSIS formula: 

p{Va) a S(V, Va) a q{V'A) A S(V', V'a) ^ r(V, V) ^ X' < X . 

Then, mark e with — x, if A(A, e, c) is valid, mark e with =x, if 
A(X, e, =) is valid, and mark e with +x otherwise. 



Now, for a set variable X we denote with £j^ the set of edges labeled with +x • 
Then, the fair Kripke structure is defined as = {G,F) where F is the set 
of strong fairness conditions containing for each edge e and each of its labels — x 
the set (e, £x)- Each fairness condition states that e can only be taken infinitely 
often if one of the edges in £^ is taken infinitely often. 

Example 6 (Szymanski cant’d). Figure 2 shows part of the abstract state graph 
after running the labeling algorithm. All =x symbols are left out and the labels 
+At “At abbreviated with +fc, — fc. The figure shows a strongly con- 




Fig. 2. Part of the labeled state graph 



nected part of the graph with the only ingoing edge in and only outgoing edge 
out. To prove communal accessibility it is necessary to show that the system 
cannot cycle forever in this component. 

It can be proved, e.g., using model-checking, that G^ H 'P- Hence, Szyman- 
ski’s algorithm satisfies DO 3p i : i G At_^ 7 . 



o 
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7 Conclusion 

We have presented a method for the verification of parameterized networks of 
finite processes. Our method is based on the transformation of an infinite fam- 
ily of systems into a single WSIS transition system and applying abstraction 
techniques on this system. We also showed how our method can deal with live- 
ness properties. We have applied this method, which has been implemented in 
our tool PAX, to a number of parameterized protocols. The obtained results are 
encouraging. 

Closest to our work is [ABJN99]. Therefore, we give a short account of the 
main differences between this and our work. While the method in [ABJN99] 
aims at computing the exact set of reachable states, our method computes an 
over-approximation. On the other hand, their method may fail because of the 
divergence of the exploration algorithm, even when acceleration is applied. More- 
over, our method can deal with a larger class of networks and with a class of 
liveness properties, often called communal accessibility. 

We intend to extend our method to deal with a larger class of liveness prop- 
erties. It is also clear that we can use WS2S instead of WSIS when we consider 
networks arranged in trees. 
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Abstract. In this paper, we present a generic tool, called FMona, for ex- 
pressing validation methods, we illustrate its use through the expression 
of the abstraction technique and its application to infinite or parame- 
terized space problems. After a review of the basic results concerning 
transition systems, we show how abstraction can be expressed within 
FMona and used to build a reduced system with decidable properties. 
The FMona tool is used to express the validation steps leading to syn- 
thesis of a finite abstract system;then SMV and/or Mona validate its 
properties. 

Keywords: abstraction, transition systems, model checker, monadic sec- 
ond order logic. 



1 Introduction 

In recent years, important work has been done in the design and implementation 
of general specification languages and validation systems. Usually, we distin- 
guish three families of tools: model checkers (SMV [BCMD90], SPIN [Hol9I]) to 
build a finite model and check its temporal properties; automatic proof tools 
(Mona [HJJ+95]) which offer a complete decision procedure if the underly- 
ing logic is decidable and proof assistants (Coq [BBC"^97], HOL [GM94] and 
PVS [ORS92]) which offer an expressive higher order logic (and thus not decid- 
able) and an assistance to the validation of formulas expressed in this logic. 

Our experience in using these tools has led us to the following observations: 

— model checkers are generally easy to use but their validation algorithm is 
“hardwired” and the available data structures are generally poor, 

— automatic proof tools lack a specification language level to express methods 

— and proof assistants lack powerful decision procedures and their integration 
is a delicate operation. Moreover their use is uneasy and require for instance 
the knowledge of the underlying type theory, the proof tactics, the tactic 
language and the underlying decision procedures. 

In this paper, we relate an attempt to overcome these problems. We have cho- 
sen an intermediate approach combining an automatic proof tool and higher level 
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aspects so that the expression of validation methods becomes easy. Of course, 
unlike proof assistants, our tool FMona cannot be used to validate the methods 
themselves. Encoded methods can only be instantiated on given applications. As 
our automatic proof tool target, we have chosen Mona as the main proof tool. 
Actually, within its underlying logic (WSIS) we can express transition systems 
and most of their basic properties without restricting to finite state spaces. In- 
deed, we can consider parameterized transition systems. We have used FMona 
to express several validation techniques, e.g. iterative methods with convergence 
acceleration over parameterized state systems and abstraction methods. In the 
following, we focus on the use of FMona to express and apply the abstraction 
method. 

The remainder of this paper is organized as follows: section 2 presents the 
logic underlying the studied validation techniques and its associated tools. Sec- 
tion 3 describes the transition system formalism and states the theorems underly- 
ing the abstraction technique. In section 4, we describe the use of the abstraction 
method to the validation of always true and simulation properties. Sections 5 
and 6 illustrate the technique on two concrete examples. Section 7 considers 
some ongoing work. 



2 Monadic Second Order Logic and Related Tools 

We recall below the definition of the two variants (WSIS and SIS) of the monadic 
second order logic of one successor [Tho90]. Then, we present the Mona tool 
deciding WSIS formulas and its high level interface FMona. 

Definition 1 (The SIS and WSIS logics) Let {a;i, . . . ,x„} he a family of 
first order variables and {Xi, . . . , X„} a family of second order monadic vari- 
ables. A primitive grammar of this logic can be defined as follows: 

— A term t is recursively defined as: t ::= 0 | Xi | s{t) 

— A logic formula f is recursively defined as: f ::= Xi{t) \ ^f | / A/ | 3xi. f \ 

/ 

Notice that the successor function s is the only function. 

Validity of a formula A closed formula is valid in SIS or WSIS if it is valid in 
the interpretation on the set Af of naturals, where s is the successor function, 
first order quantifiers relate to the naturals and second order quantifiers to the 
subsets (finite in the case of WSIS) of Af. These two logics are decidable [Tho90]. 

The monadic second order logic naturally supports the method presented 
since it makes it possible on the one hand to express the concept of sequence of 
execution on a finite state space and the temporal properties associated, and on 
the other hand the refinement relation between a parameterized concrete space 
and a finite abstract space. 
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The Mona Tool The Mona tool [HJJ+95] implements a decision procedure for 
WSIS, based on the automata theory. The Mona syntax accepts the construc- 
tions of the WSIS logic presented in the preceding section. Mona data types are 
thus limited to booleans, naturals and finite sets of naturals. Thus, propositional, 
first order and second order variables are respectively declared, existentially and 
universally quantified by var^, ex^ and all^ where i is the order of the variable. 

The FMona Tool The FMona tool [BF99b] is a high level interface for Mona. 
For instance, it is possible to declare enumerated and record with update types 
and quantify over them. Furthermore, FMona allows the definition of higher 
order macros parameterized by types and predicates. FMona source code is type- 
checked, macro expanded and translated to pure Mona. The following example 
defines the transition relation reql between the states st and st ’ . The complete 
example is given in section 5. 

type PC = {out ,req, mutex} ; type Sys = record{pcl ,pc2 : PC; yl,y2: nat;}; 
pred reql (var Sys st , st ’ ) = 

st.pcl=out & st’=st with {pcl:=req; yl : =st .y2-pl ; } ; 

Note that the expression st ’ =st with { pci := req; yl := st.y2 + 1;} ex- 
presses that st’ is obtained by updating the fields pci and yl of st. 

We will use the FMona tool to express parameterized transition systems, 
abstraction relations, the synthesis of finite abstractions and the validation of 
their safety properties (mainly the so called always true properties). 

3 The Formalism and the Basic Results 

This section presents the formalism used: transition systems [Arn92]. We recall 
then the basic results concerning transition systems. The Coq proof assistant 
has been used to formalize the definitions and to validate the stated theorems. 

Notations Given a set S', its complement is denoted S. In the following, sets and 
predicates are identified. Given a relation (p C A x B and a subset P C A, we 
note ip{P) = {y € B \ 3x ■. P{x) A (p{x, y)}. 

3.1 Transition Systems, Refinements, Simulations and 
Implementations 

Definition 2 A labeled transition system is defined by a quadruple 
where E is a set of states, I C E is the set of initial states, L is a set of labels 
and -^gExLxE is the transition relation. We will note e e' instead of 
{e,l,e') e^. 

Definition 3 (Invariance) A predicate P is invariant in the transition sys- 
tem S if: it is true over the initial states and is is preserved by each transition. 

A state s € E is reachable in S if there exists a sequence sq, . . . , Sn = s 
such that Sq G I and Vz € 0..n — 1 : Si ^ s^+i. The set of reachable states of a 
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transition system S will be denoted Acc{S). A predicate P is said to be always 
true in S if it holds in all reachable states of S. This is denoted S h UP. 

Theorem 1 (Sufficient condition for validity) An invariant property is al- 
ways true. 

Within FMona, we define the macro reachable and always_true as follows: 
pred reachable (type State, 

predCvar State s) init, pred(var State s,s’) tr, var State s) = 
ex array nat of State A: ex nat i: A[i]=s & init (A [0]) & 
all nat j where j < i: tr(A[j] ,A[j + l] ) ; 

pred always.true (type State, pred(var State s) p, 

pred(var State s) init, pred(var State s,s’) tr) = 
all State s: reachable (init ,tr, s) => p(s) ; 

Definition 4 (Refinement) Given two transition systems with the same set 
of labels L, 

C = {EcAc, L,^c) and A = (Ea, la, L,^a), and tp C Ec x Ea- C refines A 
through (p, denoted C A, if: 

— ip maps each initial state of C to an initial state of A. 

— Given two states c and c' of Ec such that c c' and a state a G Ea in 

relation with c through p, there exists a state a' G Ea in relation with c' such 
that a a' . 

Definition 5 (Run) Given a transition system S = (E,I,L,^). A run is a 
relation - A^-GExL*xE inductively defined as: 

— e e 

— if e ^ e' and e' e" then e e" 

We define the set o/ finite traces T{S) of the system S as follows: 

T{S) = {IgL* \3iGl,eGE:iAe}. 

Definition 6 (Simulation and implementation) Given two transition sys- 
tems C and A. C simulates A through p if for every state c of C reachable by 
a trace t, c has a p image reachable in A by t. C implements A if the set of 
traces of C is a subset of the set of traces of A. 

Theorem 2 (Sufficient conditions) Refinement is a sufficient condition for 
simulation. Simulation is a sufficient condition for implementation. 

The validation of always true properties relies on the following theorems 
which state two equivalent sufficient conditions; the first one is expressed at the 
abstract level and the second one at the concrete level. 
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Theorem 3 (Always true properties preservation) Given two transition 
systems C and A such that C simulates A through ip. If the abstraction of P 
by ip (ip(P)) is always true over A, then P is always true over C. More for- 
mally, we have the two equivalent formulas: 

CsimulateSipA A'^ Uip[P) Csimulates^pA p~"^{Acc{A)) ^ P 

Chap Chap ^ ’ 

3.2 Abstraction 

The abstraction technique aims at verifying the properties of a transition system 
through the reduction of its state space: the original system is said concrete and 
the reduced one is said abstract. In fact, it can be considered as the reverse of 
the refinement technique where we derive a concrete system from an abstract 
one. The abstraction technique synthesizes an abstract system from the concrete 
one. Relevant properties are studied over the abstract system and inherited by 
the concrete one. This method has been used by [CGL94] to reduce the state 
explosion resulting from an exhaustive search over a finite state space. It is also 
used by [BL098] for analyzing infinite state space systems. Given an abstraction 
function, they propose heuristics for the construction of the abstract system 
whereas in our approach the abstract system is built in an automatic way by 
the FMona tool. 

In the following, we recall the basic definitions and results. 

Definition 7 (Abstraction) Let C = {Ec, Ic, L,^c) be a transition system, 
Ea a set of so called abstract states and ip a relation over EcXEa- The abstraction 
of C through ip is the transition system (Ea, la, L, —>a) where la is the image 
by ip of Ic and for each label I, — >a is the set of images through p of the pairs 
connected by — ic. 

It follows that the abstraction of a transition can be expressed by the generic 
and higher order FMona macro: 

pred tr_a(type State.c, type State.a, predCvar State.c c, c’) tr_c, 
predCvar State.c c, var State.a a) p, var State.a a, a’) = 
ex State.c c,c’: yj(c,a) & (/5(c’,a’) k tr_c(c,c’); 

Theorem 4 (Refinements and abstractions) Let p a total relation between 
two state spaces Ec and Ea- A transition system over Ec refines its abstraction 
through p. 



4 Automatic Validation through Abstraction 

Let us recall that the abstraction introduced in the paragraph 3.2 consists in 
defining a finite reduced system starting from a concrete system, a finite state 
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space and a total relation known as the abstraction. It is the reverse of a refine- 
ment as the starting system is the concrete one. Moreover, for a refinement, the 
two transition systems are provided. 

One generally considers two approaches for the expression of properties to 
be validated: 

— the first one is based on states: a property is expressed as a temporal logic 
predicate over the state space (more exactly over the state variables defining 
the interface of the system) . 

— the second one is based on transitions: we are interested in a simulation 
property between a concrete system and an abstract system (also called the 
reference system). 

In the following, we illustrate the abstraction method by considering the two ap- 
proaches: to validate the mutual exclusion implemented by the bakery algorithm, 
we adopt a state based approach; to validate some classes of cache coherency 
protocols, we adopt the transition based approach. 



4.1 Specification and Synthesis of the Abstract Transition System 

The formulas defining the transitions of the abstract transition system, as intro- 
duced in definition 7, are quantified over the domain of the concrete space and 
thus are not propositional. It follows that the existence of a transition between 
two abstract states is not necessarily decidable. In order to be in a decidable 
context, we consider the framework of the WSIS logic for expressing: 

— the infinite or parameterized concrete state space (with first and second order 
variables), 

— the transitions of the concrete system, 

— the abstraction relation between the concrete and abstract systems. 

Thus, according to definition 7, an abstract transition is a WSIS predicate 
over two abstract variables. Consequently, the properties of an abstract system 
can 



— either be studied within the WSIS logic, which assumes the encoding of 
temporal logic operators in this formalism [Tho90]. Then, safety properties 
(which are inherited) can be expressed and automatically decided [ABP97]. 

— or be studied using a model checker as SMV [BCMD90]. Such a use requires 
the synthesis of a propositional expression of abstract transitions. Since this 
alternative resorts to a dedicated tool, it seems to be more efficient on the 
considered examples. The synthesis of the propositional expression can be 
performed through two methods: 

• by an exhaustive exploration of the abstract state space: the existence 
of a transition between two abstract states is determined by the validity 
of a closed WSIS formula (definition 7). 
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• by a symbolic reduction to propositional logic of an abstract transi- 
tion expressed in WSIS. This reduction is possible within the Mona tool 
where the set of solutions of a predicate with free variables is encoded by 
an transition system whose transitions are labeled by propositional for- 
mulas. In this context the free variables are booleans and the automaton 
generated by Mona contains a unique transition. 

Let us illustrate the synthesis of the finite transition system over a trivial 
example. The state space of the concrete transition system is a finite set of 
naturals of unknown size, the concrete transition is defined by the predicate 
Initc(S') = {S = {0}) and the transition Ttc{S,S') = 3iX,y : y S S A S' = 
S'\{y}U{a;}. As an abstraction, we consider a state reduced to a unique boolean 6, 
and the abstraction relation ip{S, b) = {b AA Vii, y : x £ S Ay £ S ^ x = y) . The 
abstract transition system is defined by the predicate Inita(6) = 325” : Initc(S') A 
(fi{S,b) and the transition Tra(6, 6') = 325, S" : (p{S,b) A Trc(5, 5') A (p{S',b'). 
The Mona tool can automatically simplify the previous monadic second order 
logic formulas to propositional formulas. Actually, we have synthesized the finite 
transition system defined by: Inita(6) = b and Tra(6, b') = b ^ b' . 

4.2 Verification of Always True Properties 

Given a total abstraction relation (p, the validation of a formula on the concrete 
transition system relies on the deduction rules of theorem 3. In this theorem, 
the abstract system is the abstraction through cp of the concrete system. By 
theorem 4, p being total, the concrete system simulates its abstraction. Then, 
the rules (1) can be simplified as follows: 

Absc^(C) h ap(p) (/j-i(Acc(Abs,^(C'))) ^ P 
CAap Chap 

Given these two rules, the validity of P is derived form the properties of 
the abstract transition system. Let us recall that the synthesis can be expressed 
in WSIS. Gonsequently, the two preceding rules give two decidable sufficient 
conditions. To summarize, given a user defined abstraction relation, we have 
two automatic verification methods: 

Method 1 

1. Gonstruction of the abstract transition system. 

2. Gonstruction of the reachable states Acc of the abstract transition system. 

3. Definition of a superset of the reachable states of the concrete transition 

system as the inverse image by p of Acc. 

4. At the concrete level, we show that p~^{Acc) P. 

Note that the term p~^{Acc) can be interpreted as a lemma automatically 
proven through an exhaustive exploration of the abstract state space. This lemma 
helps in the validation of P. 
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Method 2 

1. Construction of the abstract transition system. 

2. Computation of the abstraction of P: ^p{P)- 

3. Verification of this abstraction over the reachable states of the abstract tran- 
sition system. 

Since the abstract state space is finite, this verification can be performed by 
a model checker like SMV. This second method uses a dedicated tool for the 
verification of always true properties. 



4.3 Validation of Simulation Relations 

The goal is to determine the existence of a simulation relation between a concrete 
system and a reference system. For that, we provide a projection of the concrete 
space to the state space of reference and a total abstraction relation. Then, we 
show that the restriction of the concrete system to some superset of its reachable 
states refines the reference system. 

Thus, given a user defined projection tt and a total abstraction relation V^^bs’ 
the construction of the simulation relation automatically proceeds according to 
the following steps: 

1. Construction of the abstract transition system (WSIS): the concrete system 
refines the abstract system. 

2. Construction of the accessible states Acc of the abstract transition system 
(WSIS). 

3. Restriction of the concrete transition system to the reverse image of the 
accessible states of its abstraction. 

4. Validation of the refinement between the reduced concrete transition system 
and the reference system (WSIS formula). 

4.4 Abstraction Heuristics 

To reduce parameterized or infinite data structures, we apply the heuristics 
presented in the following paragraph. The abstraction function associates with a 
parameterized or infinite type a finite approximation. We consider three classes 
of types: integer types, arrays with opaque^ index and finite values, arrays with 
natural index and finite value, and arrays with opaque index and values. We 
have considered the following abstractions which can be expressed in WSIS: 

1. We associate with natural state space variables a family of boolean variables 
coding the comparisons between these variables or the variables and the 
constants of the problem. Notice that this heuristics is in fact the one used 
in an automatic way by [Lcs97]. 

An opaque type supports only the assignment and comparison operations. 
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2. We associate with an array with opaque index and finite values within the set 

{xi , . . . ,Xn}& family of bounded counters {ci , . . . , c„} with value in the set 
{0,... A counter Ci indicates the number of indexes with value Xi. 

This enumeration being bounded by /c, a higher number of occurrences is 
denoted +. 

3. We associate with an array t with natural index and finite values the number 
of alternations t{i) ^ t{i — 1), counted in the finite set {0, ... ,k, +}. 

4. We associate with an array with opaque index and values the number of 
different values in the array, counted in the finite set {0, ... , fc, +}. 

Notice that the heuristics we present relate to the construction of an ab- 
straction function, the abstract transition system being automatically built and 
validated by the FMona tool for the considered class of problems. On the other 
hand, [BL098] supposes the existence of an abstraction function and proposes 
heuristics for the construction of the abstract system. 

5 Application to the Bakery Mutual Exclusion Protocol 

The transition system of the Bakery mutual exclusion algorithm over two pro- 
cesses is described in FMona by the following code. Its state space contains two 
finite-typed variables pci and pc2 and two naturals yl and y2. The state space 
is thus infinite. 

type PC = {out ,req, mutex} ; type Sys = record{pcl ,pc2 : PC; yl,y2: nat;}; 

pred InitCvar Sys st)= st.pcl=out & st.pc2=out & st.yl=0 & st.y2=0; 
pred reqKvar Sys st,st’)= st.pcl=out & 

st’=st with |pcl:=req; yl :=st .y2-|-l ; } ; 
pred req2(var Sys st,st’)= st.pc2=out & 

st’=st with |pc2:=req; y2 :=st .yl+1 ; } ; 
pred enter Kvar Sys st,st’) = 

st.pcl=req & (st.y2=0 | st.yl<st.y2) & st’=st with{pcl : =mutex; } ; 
pred enter2 (var Sys st , st ’ ) = 

st.pc2=req & (st.yl=0 | st.y2<st.yl) & st’=st with{pc2 : =mutex; } ; 
pred leaveKvar Sys st,st’)= st.pcl=mutex fc 
st’=st with |pcl:=out; yl:=0;}; 
pred leave2(var Sys st,st’)= st.pc2=mutex fc 
st’=st with |pc2:=out; y2:=0;}; 

We notice that it is not possible to bound the natural variables yl and y2. Ac- 
tually, when considering the execution sequence ri(eir 2 he 2 ri/ 2 )*, the sequence 

of (yl,y2) values is > (2fc 4- 1,0) where r, e, / respectively 

abbreviate req, enter, leave. 

We seek to establish that the mutual exclusion property is always true: 

pred excKvar Sys st) = ~(st.pcl = mutex & st.pc2 = mutex); 
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The predicate excl is not an invariant. Actually, it is not preserved by 
enterl. However, as shown in the following, it is always true, i.e., true in any 
reachable state. In order to get a finite state space, the fields pci and pc2 being 
finite, it is enough to abstract the fields yl and y2. We consider the abstraction 
which consists in coding the comparisons between these two fields. Then, we get 
the abstract system Sys_a and the abstraction relation (p defined as follows: 

type Cmp = {zlz2,zl ,z2, inf 12, inf 21 ,eq} ; 
type Sys_a = record{pcl ,pc2 : PC; yly2: Cmp;}; 
pred (pCvar Sys st, var Sys_a a) = 
a. pci = st.pcl & a.pc2 = st.pc2 & 

if st.yl = 0 & st.y2 = 0 then a.yly2 = zlz2 
elsif st.yl = 0 then a.yly2 = zl 
elsif st.y2 = 0 then a.yly2 = z2 
elsif st.yl < st.y2 then a.yly2 = inf 12 
elsif st.y2 < st.yl then a.yly2 = inf 21 
else a.yly2 = eq endif; 

The relation p being total, according to theorem 4, the Bakery transition sys- 
tem refines its abstraction through p. The abstraction through p of the Bakery 
system, computed by FMona, is a finite state system of which transitions can 
be expressed using WSIS and reduced to propositional logic using Mona. Con- 
sequently, the computation of the reachable states is possible. Mona validates 
that any state reachable by this transition system cannot be the image of a state 
where two processes would not be in mutual exclusion. The following logical 
formula (extracted from the transition system produced by Mona) encodes the 
set of reachable states of the abstract system: 
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According to theorems 2 and 3, it follows that the mutual exclusion predicate 
excl is always true in the Bakery system. 

Note that the validation of the abstract system can also be achieved by SMV 
after reducing abstract transitions to propositional logic. Such a reduction can 
be performed by Mona. The following FMona predicate defines the transitions 
of the abstract system according to the abstraction relation p and the concrete 
transition relation Trans^(tr_a has been defined in section (3.1)). 

pred bakery_tr_a(var Sys_a a, a’) = tr_a(Trans ,(p, a, a’ ) ; 

^ FMona automatically synthesizes type parameters. 
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The Mona tool produces a transition system representing the reduction of the 
relation Trans_a. Since the transitions of this system are labeled by propositional 
formulas relating the arguments of Trans_a, a SMV expression of the abstract 
transition can be extracted and analyzed. 

It is interesting to note that since the abstraction did not modify the interface 
fields pci and pc2, it also defines a mutual exclusion algorithm over a finite state 
space similar to Peterson’s algorithm [PS85] comprising apart from the fields pci 
and pc2 a finite field yly2 that can be encoded by three booleans. 

6 Application to Cache Coherency Protocols 

In this section we consider cache coherency protocols for shared memory multi- 
processor machines [Stc90]. In such an architecture, each processor has a private 
cache where it stores copies of the shared memory data. The protocol ensures 
coherence between the multiple copies of a same data. Informally, atomic co- 
herency means that the processors behave as if data were not duplicated. For 
this purpose, a given finite state is associated with each copy. For instance, in 
the Illinois protocol [AB86], the State type can be encoded as the enumera- 
tion {inv, Excl, Shared, Dirty} where Inv marks an invalid copy, Excl an 
exclusively held copy. Shared a shared copy, and Dirty a modified copy. The 
data structures handled by such protocols are described by the following decla- 
rations, where Proc and Word are two opaque types. In the following, we denote 
by control the array Ctr and by data the array C and the memory M. 

var nat NProc; 

type Proc = ... NProc; type State = {Inv, Shared, Excl, Dirty}; 
type Word = recordjbl :bool; b2:bool;}; # see section 6.2 
type Sys = 

recordjCtr: array Proc of State; C:array Proc of Word; M:Word;}; 

This protocol is parameterized by the number of processors, defined by the 
type Proc, and by the size of the words, defined by the type Word. The validity of 
such a protocol is expressed either by the satisfaction of an always true property, 
or by the simulation of a canonic atomic memory [BF99b]. The canonic atomic 
transition system (6.1) includes a register and the operations for reading and 
writing in this register. 



6.1 Specification of the Transition System 

The transition system defining atomic protocols establishes the interface of a 
memory access protocol comprising the Init predicate and three transitions: 
the reading of a value v by the processor p, the writing of a value v by the 
processor p. and the Skip transition which does nothing. 

type Word = recordjbl :bool ; b2:bool;}; # see section 6.2 
pred Init.atomic (var Word r) = true; 
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pred Read.atomic (var Word v, var Word r,r’) = (v = r) & (r’ = r) ; 
pred Write_atomic(var Word v, var Word r,r’) = (r’ = v) ; 
pred Skip (var Word r,r’) = (r’ = r) ; 

The transition system of an atomic coherency protocol must implement the 
preceding reference system. 



6.2 Elimination of the Opaque Type Word 

The expression of the abstract system in the WSIS logic requires to fix the size of 
Word. For this purpose, we use the result established in [BF99a] . It concerns the 
reduction of formulas where the comparisons between elements of some opaque 
type D only occurs in terms of the form f{x) = g(x) or f(x) = k where /, g and k 
are identically quantified at the top level of the formula. Let n be the number of 
such functions or variables. The validity of the formula over a domain D of size 
> n is equivalent to its validity over a domain of size n. 

Here, the opaque type Word must be eliminated from formulas expressing 
data abstraction and transition refinement. In both cases, variables of type Word 
are either global arrays or global variables (the array of words C, the memory M 
and the value to be read or written d). According to our result, we can restrict 
the type Word to a domain of size three. Consequently, we have chosen a record 
with two booleans. 



6.3 Abstraction and Reduction 

In this paragraph, we show how the abstract transition system is actually syn- 
thesized. The abstraction relation can be structured as the conjunction of a 
control abstraction and a data abstraction. 

Control abstraction associates to the (parameterized size) array Ctr a fixed 
family of counters, through the application of the second heuristic of §4.4. Thus, 
we introduce the abstraction data type as a record with three bounded counters, 
one for shared caches, one for exclusive caches and one for dirty caches. The 
abstraction relation </3_ctr maps the Illinois control array to these counters. 

# array abstraction through bounded counters 

type B_Cpt = {Zero, One, More}; 

pred abstr_p(type State, pred(var State s) p, var B_Cpt f) = 
if all State s: ~p(s) then f=Zero 

elsif ex State si: p(sl) & all State s: S 7 ^sl=>~p(s) then f=0ne 
else f=More endif; 

type Sys_a_ctr = # abstraction of Illinois control 

record} c_Shared: B_Cpt; c_Excl: B_Cpt ; cjlirty: B_Cpt;}; 
pred (/5_ctr(var Ctr s, var Sys_a_ctr a) = 
abstr_p (pred (var Proc p) : s [p] =Shared,a. c.Shared) & 
abstr.p (pred (var Proc p) : s [p] =Excl,a. c.Excl) & 
abstr.p (pred (var Proc p) : s [p] =Dirty , a. c.Dirty) ; 
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Data abstraction associates to the array C and the memory M the cardinal, 
counted over {1, 2, +}, of the set of valid data in the system. 

type Sys_a_data = {One_d,Two_d,More_d} ; 
pred yj_data(var Sys s, var Sys_a_data c) = 

if (all Proc p: s . Ctr [p] y^Inv => s.C[p]=s.M) then c = One_d 
elsif (ex Proc p,q: s . Ctr [p] y^Inv k s . Ctr [q] y^Inv & s . C [p] . C [q] 

& s.C[p] 7^ s.M & s.C[q] 7^ s.M) then c = More.d 
else c = Two_d endif; 

Consequently, the abstract domain consists in a fixed family of bounded 
counters , defined here by the record Sys_a. The abstraction relation ip 

is then defined as the conjunction of the abstractions of the control and data 
parts. Note that for efficiency purposes, this conjunction has been restricted 
to the reachable states of the control part. Otherwise, the complexity of the 
computation is too high and the resulting formula cannot be decided by Mona. 

type Sys_a = record{ ctr_a: Sys_a_ctr; data.a: Sys_a_data; } ; 
pred (/j(var Sys s, var Sys_a a) = 

is_abs_ctr_Acc (a. ctr_a) & (/3_ctr (s . Ctr , a.ctr.a) k 93_data(s,a.data_a) ; 



6.4 Validation of the Simulation Relation 

In this section, we show the simulation of the canonic transition system, reduced 
to one register R (see §6.1) by the abstract one. Here, we are interested in the 
refinement approach. With this intention, one introduces a projection between 
the state space of the Illinois protocol and the space reduced to one register. The 
relation ill_atm expresses that the contents of the register R is either equal to 
the memory if the caches are all invalid, or equal to the common value of the 
non-invalid caches. 

pred ill_atm(var Sys s, var Word r) = 

((all Proc p : s .Ctr [p] =Inv)=>s .M=r) k all Proc p : s . Ctr [p] 7^Inv=>s . C [p] =r ; 

It should be noted that this relation does not make it possible to define a 
refinement with the atomic model. In fact, the Illinois transition system must 
be restricted to some superset, called is_Acc of its reachable states. For this 
purpose, we consider the inverse image through ip of the reachable states of its 
abstraction. 

pred is_Acc(var Sys c) = ex Sys_a a: i/p(c,a) k is_abs_Acc(a) ; 

Then, the validity of the Illinois protocol can be stated: we show that the re- 
lation ill_atm establishes a refinement between the reduced concrete transition 
system and the atomic one. More precisely, such a refinement is specified by the 
following conjunction which is transformed by FMona to pure Mona code and 
validated by Mona. 
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# Illinois validation 

ref inement.init (restrict.init (Init , is.Acc) , Init.atomic , ill.atm) & 
(all Word v: ref inement.tr (restrict.tr (Read_Miss (v) , is.Acc) 

,Read_atomic (v) , ill.atm) ) fc 

(all Word v: refinement_tr(restrict_tr(Write_Miss(v) ,is_Acc) 

,Write_atomic (v) , ill.atm) ) & 
refinement_tr(restrict_tr(Flush,is_Acc) .Skip, ill.atm) ; 



7 Other Validation Techniques 

Apart from abstraction techniques, we have also expressed in FMona iteration 
based techniques. It should be stressed that we have applied them on param- 
eterized systems. However, since the state spaces of the considered problems 
are not fixed, we have no decidability results. It follows that the user must 
provide an iteration bound to apply the proposed macros. Backward iteration 
techniques have been successfully applied to mutual exclusion algorithms on 
ring networks [Mar85]. However, forward and backward analysis fail for some 
well known problems (e.g. termination detection [DFvG83], dining philosophers, 
Szymanski mutual exclusion protocol [Szy90]). To overcome such problems, con- 
vergence acceleration techniques have been proposed [ABJN99]. The basic idea 
consists in approximating the transitive closure of the transition relation. We can 
express such techniques in FMona. In a forthcoming paper [BFOO], we present 
some new acceleration techniques and their expression in FMona. These tech- 
niques allowed us to validate the above-mentioned problems. 

8 Conclusion 

In this paper, we have illustrated the use of FMona to express the abstraction 
technique and its applications. Thanks to the higher order features of FMona, 
the validation steps of the method could be expressed in a generic way and 
instantiated on specific problems. 

FMona has also been used to express other well known methods such as it- 
erative methods applied to parameterized systems. It should be stressed that 
these methods have been generically defined and have been applied to well know 
problems (mutual exclusion on parameterized rings, parameterized multiproces- 
sor memory protocols, infinite space bakery algorithm). 

For efficiency reasons, we have also connected FMona to propositional solvers. 
We also plan to consider the validation of the methods themselves and how to 
integrate them smoothly into FMona. 
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Abstract. We consider a model for representing infinite-state and pa- 
rameterized systems, in which states are represented as strings over a 
finite alphabet. Actions are transformations on strings, in which the 
change can be characterized by an arbitrary finite-state transducer. This 
program model is able to represent programs operating on a variety of 
data structures, such as queues, stacks, integers, and systems with a pa- 
rameterized linear topology. The main contribution of this paper is an 
effective derivation of a general and powerful transitive closure opera- 
tion for this model. The transitive closure of an action represents the 
effect of executing the action an arbitrary number of times. For exam- 
ple, the transitive closure of an action which transmits a single message 
to a buffer will be an action which sends an arbitrarily long sequence of 
messages to the buffer. Using this transitive closure operation, we show 
how to model and automatically verify safety properties for several types 
of infinite-state and parameterized systems. 



1 Introduction 

In recent years, substantial progress has been made regarding the automated 
verification of finite-state systems. Fully automated techniques have now been 
developed to the extent that they can routinely handle systems with millions 
of states. Partial order techniques and symbolic representations, such as Binary 
Decision Diagrams (BDDs) [BCM+90] have been important in this development. 
There is also progress in the development of verification algorithms for infinite- 
state systems (e.g., [ACD90,AH89,BS95,Sti96,Fin94,AJ96]), and for parameter- 
ized systems, i.e., systems consisting of an arbitrary number of homogeneous 
processes connected in a regular topology (e.g., [GS92,KMM+97,ABJN99]). 

The problem of verifying that a system satisfies a certain correctness property 
is usually reduced to checking some form of reachability problem on a transition 
system model of the system. For example, verifying that a system never gets 
into an “unsafe” state consists in checking that no “unsafe” state can be reached 
(by a sequence of transitions) from the set of initial states. This problem is 
often analyzed by symbolic or enumerative state-space exploration, starting from 
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the set of initial states. However, naive reachability analysis is guaranteed to 
terminate only when the reachable state-space has finite depth, meaning that 
there is a uniform bound on the number of transitions needed to get to any 
reachable state. Finite-state systems trivially have a state-space with finite depth 
(bounded by the number of states) , but the depth of the state-space of an infinite- 
state system is in general infinite. 

In this paper, we will consider infinite-state systems whose states can be 
represented as finite strings over a finite alphabet. This includes parameterized 
systems consisting of an arbitrary number of homogeneous finite-state processes 
connected in a linear or ring-formed topology: take the (finite) set of local states 
of each process as the alphabet, and let a string of process states represent a 
system state (the length of the string is equal to the number of processes) . Our 
model also includes systems that operate on queues, stacks, integers, and other 
data structures that can be represented as sequences of symbols. We represent 
the transition relation of such a system by a finite set of actions; each action is a 
regular relation between strings, which can be represented, e.g., by a finite-state 
transducer. 

For this class of systems, reachability analysis can be performed as follows. 
Assume that a set of initial states and a set of “unsafe” states are both given as 
regular sets. Using the transducer representation of actions, we can calculate the 
set of successors of a regular set of states as a regular set. Explore the reachable 
states by successive calculations of sets of successor states, starting from the set 
of initial states. If the set of reachable states has finite depth, this exploration 
is guaranteed to terminate. Dually, we can perform the exploration backwards, 
starting from the unsafe states and taking predecessors, with guaranteed ter- 
mination if the “backwards depth” of the state-space is finite. This approach 
is pursued, e.g., by Kesten et al. [KMM+97], who illustrate their approach by 
some examples with finite backwards depth. 

In general, however, an infinite-state or parameterized system need neither 
have a finite depth nor a finite backwards depth. To explore the entire state- 
space, one must then be able to calculate the effect of arbitrarily long sequences 
of transitions. This problem would be solved if we could calculate the transitive 
closure of an action, and then adding this transitive closure to set of actions 
that are explored during verification. Remember that an action can be seen as 
a relation on states: therefore the transitive closure of an action represents the 
effect of executing the action an arbitrary number of times. For example, the 
transitive closure of an action which transmits a single message to a buffer will 
be an action which sends an arbitrarily long sequence of messages to the buffer. 
The transitive closure of an action in which a process in a parameterized system 
passes a token to its neighbor, will be an action that passes the token through 
an arbitrary sequence of neighbors to another process. 

The main contribution of this paper is a construction of the transitive closure 
for a large class of actions in the system model described above. This transitive 
closure is also representable as a finite-state transducer, and can therefore be used 
in the state-space exploration in the same way as the original actions. Further- 
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more, we show how this construction makes is possible to verify safety properties 
of many parameterized and infinite-state systems fully automatically. We reduce 
safety properties to reachability using standard techniques. To check reachability, 
we first calculate the transitive closure of each action, if possible, and thereafter 
perform reachability analysis with the extended set of actions. In many cases, 
this analysis terminates even when the state space does not have finite depth. 
We have implemented the technique, using the Mona package [HJ.J+96a], and 
present some examples. 

In order to characterize the class of actions for which our transitive-closure 
construction works, we define a notion of local depth. Intuitively, an action has 
local depth k if each position in the string is transformed at most k times in any 
sequence of executions of that action. For example, an action in a parameterized 
system, in which a process passes a token to its right neighbor has local depth 2, 
since in an arbitrary execution sequence, each process is affected at most twice: 
once when receiving the token, and once when sending the token. Similarly, if 
a queue is modeled by an unbounded array with a finite contiguous segment 
of positions filled by messages, then an action which sends a message to the 
channel, thus putting a message into an empty position, has local depth 1. The 
main theorem of the paper shows that we can calculate the transitive closure of 
any action with finite local depth, and represent it as a finite-state transducer. 
We can also approximate the transitive closure of an action which does not 
have finite local depth. For an arbitrary k, we can calculate, as a finite-state 
transducer, the action which corresponds to executing the action an arbitrary 
number of times, subject to the constraint that each position is transformed at 
most k times. 

A special case of the present paper is our earlier work [ABJN99]. There we 
consider parameterized systems, whose state can be represented by a string, 
and where each action is allowed to change the string in only one position. By 
requiring this change to be idempotent, each action gets local depth 1, and we 
could give a construction of its transitive closure. The restrictions limited the 
applicability to certain classes of parameterized algorithms. 

Related Work The use of regular sets as a symbolic state representation in 
the verification of infinite-state systems has been proposed by e.g., Boigelot 
and Wolper [WB98] and Kesten et al. [KMM+97]. Kesten et al. perform back- 
wards reachability analysis on state spaces of finite depth or finite backward 
depth. The decidability results for systems with unbounded lossy FIFO chan- 
nels [AJ96] and for well-structured systems [ACJYK96] follow from the fact 
that the considered verification problems have a finite backward depth. Other 
researchers, e.g., [F097], use regular sets in a deductive framework, where ba- 
sic manipulations on regular sets are performed automatically, e.g., using the 
Mona [H.JJ+96a] or MoSel [KMMG97] packages. In [Sis97], parameterized sys- 
tems are verified using induction on the number of processes, where the inductive 
invariant is specified using automata on two dimensional strings. 

A related technique for analyzing unbounded sequences of executions of an 
action, called acceleration, has been developed for finite state processes that com- 
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municate via unbounded FIFO channels [BG96,BGWW97,BH97,ABJ98] and for 
systems that operate on integer variables [BW94]. An acceleration of an action 
can be seen as the application of the transitive closure to a particular set of states. 
By a suitable representation, we can model the operations considered in the 
work on QDDs [BG96] as actions with finite local depth. Bouajjani and Haber- 
mehl [BH97] also perform acceleration of actions with non-finite local depth, 
sometimes resulting in non-regular sets of states. The acceleration operation is 
related to the widening operation, used for computing fixpoints in abstract in- 
terpretation [GG77], but aims at computing an exact fixpoint of a sequence of 
approximations, each of which represents a bounded number of executions of an 
action. 



Outline In the next section, we define our model of systems and illustrate it by 
modeling a parameterized termination detection algorithm intended for a ring 
topology. In Section 3, we review the principles of symbolic reachability analysis 
for verifying safety properties, and note that this analysis would be significantly 
improved by taking the transitive closure of actions. Section 4 presents the main 
result: a construction for computing the transitive closure of an action with local 
depth fc, for arbitrary k. Section 5 discusses two extra composition operations 
which also augment the power of the analysis. In Section 6, we outline how 
our results can be used for modeling and analysis of programs that operate 
on unbounded FIFO channels and integers. An implementation of our method, 
and the modeling and automated analysis of several infinite-state algorithms is 
reported in Section 7. Section 8 contains conclusions. 



2 Program Model 



In this section, we introduce our model of programs. A global state (or a config- 
uration) of a system is represented as a string over a finite alphabet C. As usual, 
C* is the set of finite strings over C. The dynamic behavior of a system is de- 
fined through a finite set of actions. Each action rewrites a certain portion of the 
string that represents the state. The rewriting relation is given by a finite-state 
transducer. The rewriting may furthermore be conditioned on the sequence of 
symbols to the right and to the left of the rewritten portion of the string. We 
use subclasses of regular languages, called left contexts and right contexts, to 
represent such conditions. 

Definition 1. A left context is a regular language which can be accepted by a 
deterministic finite-state automaton with a unique accepting state, and where 
all outgoing transitions from the accepting state are self- loops, (transitions with 
identical source and target states). A right context is a language such that the 
language of reversed strings is a left context. The tail of a left context is the 
set of symbols that label self-loops from the accepting state. The tail of a right 
context is the tail of the left context which is its reverse language. □ 
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Examples of left contexts are a* (with tail {a}), and (a+b)*b{a+b)* (with tail 
{a, 6}). An example of a regular language which is not a left context is {a + b)*b. 
This language is, however, a right context with tail {a, 6}. 

We will represent (length-preserving) relations on C* by finite-state trans- 
ducers. A finite-state transducer defines a regular language over C x C. It rep- 
resents the relation on C* which contains the pair (ciC2 • • • c„ , c'ic'2 ■ ■ ■ c'^) iff 
the transducer accepts the string (ci, c']^) (c2, C2) ••• (c„,c(j). 

We are now ready to give the formal definition of our model. 

Definition 2. A program is a triple V = (C, (f>i,A) where 

C is a finite alphabet, called the set of colors, 

4 >i is a regular set over C, denoting a set of initial configurations, and 
A is a finite set of actions. An action is a triple 

(t>L 0 

where (j)L a, left context, (j)ji is a right context, and t is a regular set over 
CxC. 

A configuration 7 of a program 7^ is a string 7(1] 7(2] • • • 7(71] over C. For a 
regular expression (f, we use 7 € ((> to denote that 7 is a string in the language 
denoted by (f). For z, j : 1 < f j < n, we use 7(1 .. j] to denote the substring 
-)[i] 7[z -I- 1] • • • 7[j]. An action 



a = 4 'l'\t^4'r 

defines a relation a on configurations such that (7, 7') S a if 7 and 7' are of 
equal length n, there are i,j with 1 < i < j < n such that 

- (7[f],7'[z])(7[z-h l],Y[z-f 1]) • (7b1,7'bD e r, 

- 7(1 .. i — l]= 7'[1 .. z — 1] e (j>L, and 

- 7[j + 1 n] = 7'b -h 1 .. n] e cj)R. 

If these conditions hold, we say that holds with active index pair {i,j). 

□ 

The above program model is a generalization of the one in our earlier 
work [ABJN99]. Our earlier model had the same structure, but the middle com- 
ponent r in an action was constrained to be a relation on C, instead of a (regular) 
relation on C* , implying that each action can only change one position in the 
string. With the new definition, a much wider class of systems can be modeled. 

Example To illustrate our program model, we will model an algorithm for ter- 
mination detection in a ring-shaped network, due to Dijkstra, Feijen, and van 
Gasteren [DFvG83]. The algorithm is intended to detect termination of an un- 
derlying computation among a ring of N processes, numbered from 1 to N. Each 
process can spontaneously change state from computing (non-idle) to idle, but 
process i can change from idle to computing only if process i — 1 (or if z = 1) is 
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computing. The system is terminated when all processes are idle. The detection 
algorithm employs a token, which is sent around by process 1 , when it is idle, 
in increasing order of indices until it reaches process 1 again. When the token 
is sent out, it is white. Each process passes the token on, and paints it black if 
it is non-idle. If it comes back to process 1 and is still white, then termination 
is signaled provided that process 1 was idle during the entire round. Otherwise 
another round of termination detection will be started at a later moment. 

We model the state of the algorithm by a string, where the ith element 
represents the state of process i. The state of process i is defined by a boolean 
variable qi which is true iff process i is idle, and a variable ti ranging over 
{black, white, none}, which has value none when process i does not have the 
token, and otherwise denotes the color of the token. In addition, process 1 has 
a boolean variable wasq (w for short), which is true if it has stayed idle during 
the current round. Thus, the set of colors is the set of triples of form {q,t,w) 
where q and w are boolean, and t € {black, white, none}. The value of w is 
relevant only in position 1 . 

The set of initial states of the system, in which process 1 has a black token, 
is described by the regular expression 

(t = black) (t = none)* 

where we use predicates to denote sets of colors, e.g., {t = black) denotes the set 
of triples {q, t, w) such that (t = black). An undesired state, in which detection is 
signaled although the system is not terminated is given by the regular expression 

|^(t = white A w) true* ~^q true*] U [{^q A t = white A w) true*] 

which states that the condition t = white A w for process 1 to signal detection 
is satisfied, but some process is not idle. 

Let us then give examples of actions. An action in which some process i with 
1 < i < iV passes the token to its next neighbor, possibly after painting it black, 
is described by the action {t = none)+ {t = none)* where r is the relation 
between strings of length two such that 

T ( {qi,ti,wi) {q2,t2,W2) , {q[,t[,w[) {q'^.t^.w^) ) 

iff q'i= qi, q '2 = Q 2 , t 2 = t[ = none, and t 2 ' = if qi then ti else black. 
We also need an action which models the passing of the token from process N to 
process 1. This is the action {e} {e} where r is the relation between strings 

of length at least two such that 

t{ {qi,ti,wi) -f {q 2 ,t 2 ,W 2 ) , {q[,t[,w[) j {q' 2 ,t 2 ,W 2 ) ) 

where 7 is any string in (t = none)*, where q '2 = q 2 , = 9 ij ti = t '2 = 

none,, and where t[ = if <72 then ^2 else black. In addition, we need an action 
for passing the token from process I to process 2, which is given in an analogous 
way. In Section 4, we will see that the first action has local depth 2, and that 
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its transitive closure represents an action which passes the token from position i 
to position j for arbitrary 1 < i < j < N . However, it is not meaningful to 
take the transitive closure of the second action, since it disables itself after being 
executed. 

Summarizing, we see that the passing of a token from one process to the next 
is modeled by one action for the “standard” case 1 < i < iV and by separate 
actions for special cases, such as passing from iV to 1 , and passing from 1 to 2 . 
The changes to q, modeling the underlying computation, can be modeled in a 
similar way. 

The above algorithm is an example of a parameterized distributed algorithm 
which assumes a linear or ring topology. In our earlier work [ABJN 99 ], we were 
able to model a restricted class of parameterized algorithms where only one 
process changed its local state in each transition. In the above algorithm, two 
processes change their state simultaneously. In Section 6, we will describe how 
we can also model and analyze programs that operate on unbounded queues, 
and unbounded integers. 

3 The Reachability Problem 

We write 71 — > 72 to denote that 0(71, 72) for some action a & A. We use — ^ 
to denote the transitive closure of — >. A configuration 7 is said to be reachable 
if there is a configuration 7/ e (j)i such that 7/ — *■ 7. 

The reachability problem is defined as follows. 

Instance A program V and a set of configurations of V represented by a 
regular expression (jjp. 

Question Is any j G cj>F reachable? 

It is well-known (e.g., [VW86]) that the problem of verifying linear-time 
safety properties can be transformed into the problem of checking that a set of 
“bad” states is not reachable. 

The reachability problem can be analyzed using standard symbolic reachabil- 
ity analysis to explore the state-space. The analysis maintains a set of reachable 
configurations, which is initially the set of initial configurations. At each step 
of the algorithm the set of reachable configurations is extended with the config- 
urations that can be reached by executing some action in the program from a 
configuration in the current set 

We use regular sets of strings to represent (in general infinite) sets of config- 
urations. A regular set is represented by an automaton. The effect of executing 
an action, which is represented by a finite-state transducer, can be calculated by 
computing, in the usual way, the product of the automaton and the transducer, 
and then projecting on the second component in the alphabet of the transducer. 
This approach is proposed and described in more detail in [KMM+ 97 ]. 

A limitation of the above approach is that it can only explore state spaces 
of finite depth^. After k iterations, one can only explore configurations at a 

^ the depth of a state space is the maximal distance (measured in computation steps) 
from the set of initial states to any reachable state 
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distance at most k from the set of initial configurations. For instance, in the above 
algorithm one can only explore the effect of passing a token through a sequence 
of k processes. To explore the entire state-space, one must in general be able to 
calculate the effect of executing arbitrarily long sequences of computation steps. 
This can be done by augmenting verification by adding the transitive closure of 
an action, i.e., the effect of executing an action an arbitrary number of times. For 
example, the transitive closure of the first token-passing action in the previous 
example, is an action in which the token is passed through an arbitrary sequence 
of neighbors to another process. In the next section we show how to compute 
the transitive closure of a large class of actions. 

4 Computing the Transitive Closure 

In the previous section, we showed how to use actions in the symbolic reachability 
analysis by representing the effect of executing an action in terms of a finite-state 
transducer. For a subclass of actions, we will now show how to represent the effect 
of an unbounded number of executions in terms of a finite-state transducer. We 
will classify actions according to a local depth, which is the maximum number of 
rewritings of a symbol in a configuration, defined more precisely below. 

As usual, let a* denote the relation on strings, which is the reflexive and 
transitive closure of a. Let a~^ denote the transitive closure of a. For an action 
a, we say that a sequence of configurations 70, • • • , 7m is a configuration sequence 
of a with active index pairs (h, I'l) ■ ■ ■ {Im, I'm) ^or each p with 1 < p < m we 
have that a(7p_i,7p) holds with active index pair {lp,l'^). 

Definition 3. A configuration sequence 70,- '■ of a has local depth k if 
each position i > \ satisfies \{p : Ip < i < l'p}\ < k. An action a has local 
depth k if whenever (7, 7') G a* then there is a configuration sequence 70, • • • , 7 m 
of a with local depth k such that 7 = 70 and 7 m = l' ■ □ 

For an action a with local depth k for some k, we can represent by a finite- 
state transducer, due to the following theorem. 

Theorem 1. Let a = 4 >l on action with local depth k for some k. 

Then oA is a regular relation on strings, which can be represented by a finite- 
state transducer with no more than ■ (|r| -I- 1 )^ -I- \4>l \ + \ fiR\ states, where 
|i?| is the number of states in the automaton representing R. 

Proof (Sketch) Let a = 4 >l 0 fin be an action as above. For each pair of 
configurations (7,7^ in oA ■, we can establish matrix of the form: 



,1 

to ^ 


t\ 




■■ 


,1 

' ’ ^n-1 ^ 




2 

to ^ 




lAcl) 


tl ■■ 


,2 (^-4) 

' ' ^n-1 ^ 


tl 


to ^ 


ti 


/ m-1 m.' 

(*^2 ^2 : 


^2 ' ■ 


±m ' n - 

' ' ^n-1 ^ 


^ j.m 
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where 

— is a state in the transducer for a, for every i,j. 

— tg is a starting state and is an accepting state of the transducer for a, for 
every j. 

— t — ^ t' iff the transducer for a can make a transition from t to t' on (c, c'). 

— c° = 7[z] and c™ = for every i. 

In the transducer for a, let ql be the accepting state of 4 >l and qR be the starting 
state of (j)R. From the definition of contexts, it follows that each column in the 
above picture is either 1) a sequence of identical states in the transducer that 
copies 4 >l, 2 )a sequence of identical states in the transducer that copies (j)R, or 3 ) 
a sequence consisting of occurrences of ql, Qr, and states inside the transducer 
for T. 

The main step of the proof is now to show that if we can construct a matrix 
as above, then we can construct a matrix in which all columns of the third form 
are sequences of form 



Wq ri wi r2 W2 ■■ ■ wi-i n wi 

where I is at most the local depth of a, where each rj is a state in the transducer 
for T, and where each Wj is in one of the seven sets (this is where the number 7 
in the theorem comes from) 

{£} qt qtq^ q^t qUtq^ qtqUt 

This can be proven by starting from an arbitrary matrix as above and permuting 
its rows when some column has too many consecutive alternations of qr and qr 
until it is on the just described regular form. If the permutation of rows is done 
carefully, the initial and final configurations (7 and 7') are not affected. 

We finally observe that the number of consecutive qr’s in a column is unim- 
portant for the effect to the left of that column, and vice versa for the number 
of consecutive qr's. By disregarding the number of repetitions of qr’s and 9ij’s, 
we get a finite number of different possible columns. Each such column will be a 
state of the transducer for , and we build a transition relation which emulates 
the effect of the above matrix. □ 

As a corollary, we note that we can also approximate the transitive closure of 
an action which does not have a finite local depth. More precisely, for an action 
a, define the approximation to local depth k of a* as the set of pairs (7,7^ such 
that there is a configuration sequence 70, • • • , 7m of a with local depth k where 
7 = 7o and 7m = "f' ■ From the construction in Theorem 1 it follows that we 
can compute the approximation to local depth k of the transitive closure of any 
action, represented as a transducer. 

5 Compositions of Actions 

For some algorithms, we need to add actions representing the composition of 
two or more actions. In combination with the transitive closure operation, this 
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makes it possible to compute the effect of an unbounded number of executions 
of a sequence, e.g. a loop, or a choice, e.g. modeling an if-statement, consisting 
of the actions in the composition. 

Let a = 4 >l (l>R and a' = (p'^ \ t' \ be two actions. Their sequential 
composition can be defined as 



(I^L n (pL 



TOT 



(t>R n (pR 



where tot' is the transducer corresponding to the relational composition of the 
relations given by r and t' . Their union can be similarly defined as 



(pL n (P'r tUt' (pR n (P'r 



where r U r' is the union of r and r' . We note that the intersection of two left 
contexts is always a left context, and similarly for right contexts. 

As an isolated operation, composition does not add to the power of reach- 
ability analysis. If, however, used in combination with the transitive closure 
operation, i.e., using the transitive closure of composed actions, it can often give 
extra power to the reachability algorithm. 

An important observation is that, in an action which is the result of a com- 
position operation, it is sometimes possible to extend the left or right context 
by including a part of the string which is transformed by r, if r leaves that part 
unchanged. As a concrete example, if t\ changes the first position from a to b 
and T 2 changes the first position from b to a, then the left context of the se- 
quential composition of these two actions may be extended by an extra symbol, 
which then has to be a. After having the context in this way, the local depth of 
the action may decrease, thus giving even more power to the transitive closure 
operation. 



6 Modeling Different Classes of Infinite-State Algorithms 

In Section 2, we showed how to model a parameterized algorithm in which each 
computation step changes the state of 2 processes. In this section, we will show 
how our framework can also be applied to programs operating on unbounded 
FIFO channels, and to certain programs that use unbounded sequence numbers. 
In Section 7, we show how algorithms in these classes can be verified automati- 
cally, thanks to our transitive closure operation. 



6.1 Programs Operating on Unbounded FIFO Channels 

In this subsection, we outline how our framework can model and analyze pro- 
tocols in which a set of finite-state processes communicate by sending messages 
over a set of unbounded FIFO channels. The verification of such protocols has 
been considered by Boigelot and Godefroid, [BG96,BGWW97], who propose to 
use a representation called QDDs (Queue Decision Diagrams) to represent sets 
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of states of such a system. QDDs are essentially automata which recognize the 
contents of the channels. In the paper [BG96] it is shown how to calculate the 
effect of exploring the acceleration of certain actions from a given set of states 
represented as a QDD. We will here show how transitive closure of corresponding 
operations can be calculated in our framework. 

For this presentation, consider a system of two finite-state processes that 
communicate via one unbounded FIFO channel in each direction. Assume that 
the control state of each process belongs to a set Q of control states, and that 
each channel contains a sequence of messages in some finite set M. A state of 
the system, where the processes are in control states qi and q 2 , respectively, and 
the channels contain the sequences wi and W 2 , respectively, can be represented 
by a string in the set given by the regular expression 

qi q 2 -L* wi _L* || _L* 1 V 2 -L* 

where the symbol _L represents an empty position in a channel, and || is used 
to separate the syntactic representations of the channels from each other. Thus, 
the representation of each channel is surrounded by “padding” with an arbitrary 
number of _L symbols. This allows each the contents of a channel to expand to the 
right when messages are inserted, and to shrink from the left when messages are 
removed. Of course, each particular representation of a system state allows only 
a finite number of insertions into a channel before all the T symbols are “used 
up”. However, since the padding can be arbitrarily long, we can capture the 
effect of arbitrarily long but finite sequences of insertions and removals, which 
is sufficient for analyzing safety properties. 

An operation in which the first process changes control state from qi to 
q[ and sends message m to the first channel, is modeled by an action which 
changes q\ to q'^ and changes any sequence of form wi || with U 2 > 1 
into wi m ||^ jf the action is idempotent, and it is thus not 

interesting to compute its transitive closure. If q\ = q'l, then we can calculate its 
transitive closure. We must then first represent the action with contexts as 

qi Q 1.* M*\f] T* II T* M* T* 

where r changes the one-symbol string T into m. This action has local depth 1, 
and we can compute its transitive closure. The transmission of a sequence of 
messages to a channel, or the reception of a sequence of messages from a channel, 
can be represented in an analogous way. 

A more challenging operation is one in which the first process in control state 
qi receives message m from the second channel and transmits it to the first. For 
the special case that our state representation has no padding symbols T around 
the separator ||, we can model the operation by the action 

qx Q L* M* M* T* 

where r transforms strings of length 2 of form || m into m || . This action 

has local depth 2, and we can therefore calculate its transitive closure. However, 
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this transitive closure results only in states without padding symbols _L around 
the separator ||. After applying the transitive closure, we must therefore “renor- 
malize” the representation by a non length-preserving transformation which in- 
serts an arbitrary amount of padding around the separator || . This representation 
can be performed directly on the regular expression or automaton. As with the 
previous operation, we can generalize this treatment to operations that receive 
a sequence of message from one channel and transmit a sequence to another. In 
Section 7, we describe how the above method has been used to generate the set 
of reachable states of a version of the alternating-bit protocol with unbounded 
FIFO channels. 

6.2 Programs Operating on Integers 

We will also give a sketchy presentation of how systems that operate with inte- 
gers, e.g., as counters or sequence numbers, can be modeled. The state of such 
a system can be modeled by letting the string represent the number line with 
the values “laid out” at the position corresponding to their value. Thus, the set 
of colors has a bit for each variable, which is true if the variable has the value 
corresponding to that position. The number line is infinite, but it suffices that we 
represent an arbitrary finite segment which contains the values of all variables. 
Thus, the predicate a; -|- 2 = j/ is modeled by the regular expression 

(^x A ~^y)* X A^y (->x A ~^y) ~^x Ay (^x A ~^y)* 

It should not be difficult to see that we can represent, e.g., incrementation of a 
variable by a constant under some conditions, and compute the transitive closure 
of such an action. In Section 7, we describe how the above method has been used 
to generate the set of reachable states of a version of a sliding window protocol 
with unbounded sequence numbers. 

7 Experiments 

We have implemented a special case of the method described in this paper, for 
actions that have a local depth of 2 and where the sequence of active index pairs 
in a configuration sequence is either increasing or decreasing. The implementa- 
tion builds a transducer for the transitive closure of each action and converts 
the union of these transducers into the DFA library of MONA[KM98,HJJ+96b] 
which is implemented using BDDs[Bry86] to represent the transitions. Using the 
implementation, we have modeled and generated the set of reachable states of 
the following algorithms: 

Parameterized Mutual Exclusion Algorithms We have analyzed idealized 
versions of parameterized algorithms for mutual exclusion, including Szy- 
manski’s algorithm, Burns’s and Dijkstra’s mutual exclusion algorithms, and 
the bakery and ticket algorithms by Lamport. Several of these could be han- 
dled by the limited framework in our earlier work [ABJN99]. 
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Parameterized Distributed Algorithms As an example of a parameterized 
distributed algorithm operating on a ring, we have considered the termina- 
tion detection of Dijkstra, Feijen, and van Gasteren [DFvG83], presented in 
Section 2. 

Algorithms operating on unbonnded FIFO channels . We have modeled 
and analyzed the Alternating Bit Protocol with unbounded FIFO channels. 
We have used the model of [AJ96]. 

Algorithms with unbonnded sequence nnmbers . We have modeled and 
analyzed a sliding window protocol, in which the maximal sequence number 
is a parameter n. The sender window has size n and the receiver window 
size 1. We use a version where the channel from the sender to receiver has 
a capacity of 3 messages, and the channel from the receiver to the sender is 
synchronous. The length of the channels can of course be changed. However, 
we have not figured out how to model and analyze the case where both the 
channels and the sequence numbers are unbounded 

In Table 7, we show for each algorithm the domains of the variables that are 
infinite, the number of steps required to generate the set of reachable configura- 
tions, the size of the transducer, the maximum number of states among automata 
generated during analysis, and the maximum number of BDD nodes among au- 
tomata generated during analysis. Note that all automata are deterministic. 

8 Conclusions 

We have presented techniques for reachability analysis of parameterized and 
infinite-state systems whose state can be represented as a string over a finite al- 
phabet. Since naive symbolic reachability analysis does not in general converge 
for such systems, we propose to use acceleration of actions to obtain termination. 
The main contribution is the definition of a notion of local depth of an action, 
and the construction of the transitive closure of an action with finite local depth, 
in the form of a finite-state transducer. We have shown that with this frame- 
work, we are able to model and verify a variety parameterized algorithms, and 



Table 1. Experiments 



Algorithm 


Domains 


Steps 


Size 


Max 

states 


Max 

BDD 


Szymanski 


process id 


8 


26 


144 


3574 


Dijkstra 


process id 


15 


22 


2503 


81487 


Bakery 


process id, integers 


5 


10 


32 


163 


Ticket 


process id, integers 


3 


12 


30 


338 


Burns 


process id 


5 


14 


111 


2445 


Termination detection 


process id 


7 


29 


133 


1497 


Alternating bit protocol 


queues 


15 


67 


4000 


66149 


Sliding Window: queue length 3 


integers 


21 


45 


339 


4788 
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infinite-state systems operating on queues and integers. In comparison with our 
earlier work [ABJN99], we are able to cover a much broader class of systems. For 
instance, we can model systems of finite-state processes that communicate over 
unbounded FIFO channels, and perform transitive closure operations that are 
analogous to the meta-transitions presented by Boigelot and Godefroid [BG96] , 
using QDDs. Our work is not more powerful, but shows how the techniques can 
be seen as part of a uniform framework. 

Future work includes the treatment of liveness properties. 
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Abstract. Conformance testing is still the main industrial vali- 
dation technique for telecommunication protocols. The automatic 
construction of test cases based on the model approach is hindered 
by the state explosion problem. Our method reduces its magnitude 
by reconsidering the test case generation at a higher level and by 
taking advantage of some static analysis techniques, in particular 
the slicing techniques. The specification is simplified by pipelining a 
set of three modules, each one implementing a different slicing technique. 

Keywords: conformance testing, asynchronous systems, static 

analysis, slicing, bisimulation 



1 Introduction 

Conformance testing is a well-established technique for the validation of telecom- 
munication protocols. Currently, it is still the main validation technique used 
at an industrial scale, given the inherent complexity of more ambitious tech- 
niques such as formal verification. Moreover, in the case of protocols, the confor- 
mance testing was completely formalized by [22,7,15] and is also standardized 
within [12]. Test cases can be automatically generated from formal specifications 
and tools such as TGV [11], tveda [18], autolink [21] or torx [2] concretely 
implement this activity. 

In the model-based approach, test cases are usually constructed by exploring 
a synchronous product between the model of the specification and some test pur- 
pose, both represented as labeled transition systems. The central problem arising 
here is the well known state explosion problem. To deal with it we propose to 
reconsider the test generation at a higher level i.e., to work with specifications 
and test purposes represented by some kind of extended automata and to per- 
form relevant static simplifications before generating test cases. In this paper, 
we consider specifications as asynchronously communicating extended automata 

* Work partially supported by Region Rhone- Alpes, France 
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and test purposes as acyclic automata with constraints. We want to generate 
tests describing a finite interaction between the tester and the implementation 
under test. Moreover, by the fact that the test purpose is an automaton with 
constraints, it is possible to generate symbolic tests. 

We propose to simplify specifications by means of slicing [23]. A first slicing 
consists in taking into account the set of interactions between specification com- 
ponents, starting from inputs enabled in the test purpose, and regardless the 
signal parameters. We obtain a first reduction of the specification, consisting of 
the part of it which is reachable given the enabled inputs. Then, for the second 
slicing, we look at the set of variables and parameters which are relevant to 
outputs observed by the test purpose and safely discard the others. Finally, the 
specification is sliced with respect to constraints attached to the test purpose. 
These analyses transform specifications without loss of information with respect 
to the test purpose. They are independent of each other and can be implemented 
separately. Each of them inputs a specification, performs a slicing on it, and then 
outputs a new equivalent one. They can be applied in any order, until no more 
reduction can be obtained. Concerning the overall simplification on the initial 
specification, our experiments showed very good results. 

The idea of using static analysis to improve model checking and test genera- 
tion was already being investigated in different contexts. For instance, tveda [18] 
produces test cases from SDL specifications by performing simple syntactic trans- 
formations on them. Slicing is used in the context of automatic generation of 
test data for sequential programs. In [13], the authors present an approach to 
selective regression testing using slicing. Selective regression approach identifies 
the parts of the program that are affected by a change. In [14], slicing is used 
for verification purposes, to extract finite-state machines from multi-threaded 
programs. 

The paper is structured as follows. Section 2 briefly remember the notions of 
conformance testing and presents the underlying model. In section 3 we propose 
and formalize three new slicing techniques of the specification with respect to 
the test purpose. Finally, we give some results in section 4 and we conclude in 
section 5. 

2 Conformance Test Case Generation 

This section reviews some notions of conformance testing and presents the under- 
lying model, which is parallel asynchronous processes communicating via queues. 

Conformance testing is a black-box testing method, which aims at validating 
that the implementations of protocols conform to their specifications. Confor- 
mance testing activity is standardized in [12] and work has been done to formalize 
it [22]. In this context, our purpose is to generate automatically conformance test 
cases for telecommunication protocols. 

In the classification of testing architectures from [12,20], our method is a lo- 
cal single-layer test method with synchronous communication between the tester 
and the implementation under test (iut). It is local because in the interactions 
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between the tester and the lUT no event caused by the surrounding environment 
appears. It is single-layer because we test implementations of specifications or- 
ganized in one layer. The tester interacts with the lUT via some points of control 
and observation (PCOs), which, in our case, are seen as external queues of the 
specification (see below). The communication at the PCOs is synchronous. This 
architecture is pictured in Figure 1. 

In order to assure the feasibility of our method (correctness, compatibility 
with the industrial practice) we require that the tester, the lUT and the specifi- 
cation satisfy some conditions : 

1. controllability condition : the tester always controls its outputs and can feed 
the specification only at one PCO at the time (therefore, for each state of the 
test purpose, whenever an input is enabled, it is the only transition starting 
in this state), 

2. consistency relation : between the test purpose and the specification (which 
ensures that the set of behaviors described by the test purpose is included 
in the set of behaviors described by the specification)^, 

3. conformance relation : ensures that the outputs of the implementation must 
be produced also by the specification. 




Fig. 1. Test architecture 



2.1 The Specification 

We consider specifications consisting of asynchronous parallel composition of a 
number of processes that communicate through parameterized signals passing via 
a set of unbounded fifo queues. We distinguish between internal queues (closed 
inside the specification) and external queues (opened to the environment). In the 
context of conformance testing with local tester, external queues contents are 
controlled by the tester. Then, we make explicit the assumption of synchronicity 

^ This assumption is strong, however it can be verified during the test generation 
process (as in TGV [10]). 
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between the tester and the lUT. Processes are extended finite-state automata. 
They perform actions on queues and local variables. For the sake of simplicity, 
the actions are simple guarded commands. 

Definition 1 (specification syntax). A specification SP is a tuple {S,C,P) 
where S is the set of signals, C = C*”* U C®®* is the set of queues (internal 
and external ones) and P is the set of processes. A process p G P is a tuple 
(Xp,Qp,Tp,qp) where Xp is a set of local variables, Qp is a set of states, Ep 
is a set of actions which can he performed by p, and Tp C Qp x Ep x Qp is a 
set of transitions. An action can he either a guarded assignment [ b ] x := e, a 
guarded input [ b ] c?s(a;), or a guarded output [ b ] c!s(e). Above, b and e are 
expressions, x G Xp is a variable, c G C is a queue and s G S is a signal. 

We give the semantics of specifications in terms of labeled transition systems. 
We assume the existence of the universal domain D which contains the values 
of variables and signal parameters. We suppose that the boolean values {t,f} 
and also the special undefined _L value are contained in D. We define variable 
contexts as being total mappings p : IJpep Xp ^ D which associate to each 
variable x a value v from the domain. We extend these mappings to expressions 
in the usual way. We define internal queue contexts as being also total mappings 
S : ^ {S X D)* which associates to each internal queue c a sequence 

(si, Pi), ..., (sfe, Vk) of messages, that is pairs (s, v) noted also by s{v), where s is 
a signal and v is the carried parameter value. We assume also the existence of 
some special undefined message a. The empty sequence is noted with e. 

Definition 2 (specification semantics). The semantics of a specification SP 
is given by a labeled transition system SP = {Qsp,Tsp,(f)p). States qsp of this 
system are triples of the form {p, S, 9), where p is a variable context, S is a queue 
context and 6 = (qi,...qn) G Xp^pQp is a global control state. Transitions are 
either internal and labeled with t, when derived from assignments or internal 
communication, either visible and labeled with the concrete action when derived 
from external communication. Transitions are constructed by the following rules: 

qJ^lEX^'q^ p{b) = t p(e) = v p{b) = t p{e) = v cG 

(p, S, 9)-^{p[v/x],5, 9') 9f^\p, 5, 9') 

p(5) = t p(e) = V c G C*”* (5(c) = w 
{p, 6, 9)^{p, 5[w.s{y)/c],9') 

p(5) = t c e p{b) = t c G C*”* 5(c) = s{v).w 

where 9' was obtained from 9 by considering one step in process p from qp 
to q'p, and the initial state q^p is obtained considering the default value of the 
variables, empty queues and processes initial states. 
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2.2 Test Purpose 

The test purpose is an acyclic finite state automaton which describe a pattern 
of interactions between the tester and the lUT. It is described from the imple- 
mentation side i.e., inputs and outputs in the test purpose means respectively 
inputs and outputs in the implementation. It contains both constrained signal 
inputs and unconstrained signal outputs. 

A constraint C is a boolean combination of atoms, each of them being a 
particular restriction on the used value. For example, we can test the containment 
of an element to an interval or to a set of values. The notation v \= C stands 
for the value v satisfies the constraint C. For a given input of the test purpose, 
there is a constraint related to the signal parameter [12]. There are no relational 
dependencies between constraints attached to different inputs. 

This test purpose definition was inspired by ttcn and has the following 
intuition : if the tester provide a signal to the implementation with the value 
of its parameter satisfying a constraint then we would like to approximate the 
value of outputs parameters. 

Definition 3 (test purpose). A test purpose TP is a tuple {Qtp, Ttp, q^p, Qtp‘^) 
where Qtp is a set of states, Ttp C Qtp x Etp x Qtp is a set of transitions 
and Qtf^ C Qtp is a set of accepting states, without successors by Ttp. Stp is 
the set of interactions atp which can be fixed within the test purpose. This set 
contains both constrained signal inputs of the form c?s(C) and unconstrained 
signal outputs of the form c!s(*), where c G is an external queue and s G S 
is a signal. C denotes a generic constraint e.g., interval constraint, on the received 
value and * denotes any value. 

The feeds are the set of inputs we intend to supply to the lUT during the 
test. Feeds are a parameter completely controlled by the tester. They will be 
taken into account during the test case generation process. That is, any external 
input in the specification will be enabled if and only if it is contained in the set 
of feeds. Intuitively, the set of feeds must cover the set of inputs given in the test 
purpose. 

Definition 4 (feeds). The feeds Ef are a set of constrained signal inputs 
{c?s(C) \cGC^^\sG S}. 

2.3 Synchronous Product 

The tests are automatically derived by exploring a kind of synchronous prod- 
uct between the model of the specification {Qsp,Tsp, q^p), the test purpose 
{Qtp,Ttp,q^p,Qff‘^), and taking into account the set of feeds Ef = (c?s(C) | 
cGC^^\sGS}. 

Definition 5 (synchronous product). We define the synchronous product 
Y[{SP,TP,Ef) as the labeled transition system (Q,r, Fn-, <Z°), with Q^^ C Q^p x 
Qtp, where Qt^ and T^^ are the smallest sets obtained by the application of the 
following rules: 
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{Qsp-! ^tp) ^ 



i^sp^Qip) € Qtt Qsp ^Qsp ^ip ^ Qtp 
{Qsp^^tp) € Qtt {Qsp^Qtp) ^i^sp^^tp) 



(.Qsp^Qtp^ € Qtt 
{Q sp-J ^tp) ^ Q 77 



\ ^ /O - c?s(C) , |_ 

\Q_sp-) Qtp) ^ Qtt ^ Qsp Qtp ^ Qtp V \= C 

{Qsp^Qtp) ^ Qtt {Qsp-iQtp) ^ (.QspiQtp) 
c? s (i^) 

{.Qsp: Qtp) ^ Qtt Qsp ^ Qsp c?s(C) € 'U 1= C 
i^spjQtp) € Qir {QbptQIp) ^ {QspT^tp) 



^ c!s(i!) c!s(*) , 

gsp ^ ^sp Qtp ^ Qtp 



{Qsp-; Qtp) € QtT Qsp ~ ^ Qsp 



{QspjQtp) ^ i^spy^tp) {QspT^tp) € Qt! {Qsp7<ltp) ^ iQspiQtp) 



Example 1. The previous definitions are exemplified in Figure 2. The specifica- 
tion is composed of two processes which communicate through an internal queue 
cl G C®"*. The external queues of the specification are ci,co € C®^*. The set of 
feeds are Ef = {cz?sr([l, 10])}. This example will be used throughout the pa- 
per in order to picture the changes of the specification induced by the following 
slicing algorithms. 




3 Static Analysis for Testing 

The purpose of static analysis is to compute, given the test purpose and the 
feeds, the part of the specification which is relevant to them. We present three 
kinds of analyses : 
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1. the relevant control analysis: restricts the processes contained in the specifi- 
cation, to the sets of states and transitions which might be statically reached, 
given the set of feeds, 

2. the relevant variables analysis: computes and simplifies processes, with re- 
spect to variables which might be used to compute values needed for outputs 
mentioned in the test purpose and 

3. the constraint propagation: aims to further simplify processes, given the con- 
crete constraints attached to feeds. 

Each one of the analysis takes as input a specification and provides an equiv- 
alent one with respect to the test generation method presented below. They 
are completely independent and can be applied in any order. Furthermore, they 
could be applied iteratively as the code optimization techniques ([17]). The re- 
duction obtained by one can be further exploited by another and so on, until no 
more reductions are possible. 

We detail each one of these analysis below and illustrate them on the example 
presented before. 



3.1 Relevant Control Analysis 

A conservative approximation for the specification is computed, by taking into 
account the set of feeds. We restrict each process to the set of states and tran- 
sitions that might be reached given the feeds. Intuitively, this analysis can be 
seen as building the largest sub-processes, after the removal of external inputs 
uncovered by feeds, and subsequently the internal inputs uncovered by internal 
outputs. 



Definition 6 (slicing wrt feeds). We define the slice of a specification SP = 
(5, C, P) with respect to a set of feeds Sf to be the specification SP\f Sf = 
{S,C,P \f Sf), where P \/ Sf contains a sliced process p' for each process 
p G P. The slice for a process p = {Xp,Qp,Tp,q^) G P is defined as the process 
p' = (Xp,Qp,Tp,qp), with the same sets of variables. The sets of states Q'p C 
Qp and transitions Tp C Tp are defined as the smallest ones which satisfy the 
following rules: 



€ Q'p 



^ Dl V>W=e , 
qp G Qp qp > qp 

Qp € Qp qp^ - — > q'p G Tf 



[6]c!s(e) , 

Qp G Qp qp > qp 

[6lc!s(e) , 



Qp e Q'p Qp'^"-^"\'p c G clsjC) G Sf 
Q'p e Q'p qp"^^"\'p G t; 

[b]c7s(x) ■ ( [h']c!s(e) 

Qp^Qp Qp > Qp cG C™" dr.qr > q'^ G T; 

, ^ [fc]c?s(a;) 

Qp &Q p Qp — > G Ti 
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We must notice here the input/output propagation between processes. That 
is, we keep an input inside some process p if and only if there exists some dual 
output enabled in some other process r. 

The algorithm computing the sliced system proceeds in an iterative manner. 
It maintains the sets of states and transitions reached for each process. Initially, 
the sets of states contain the initial state of the processes, and the sets of tran- 
sitions are empty. Then, at each step, one of the rules before is applied until the 
least fixed point is reached and no more rule is applicable. 

This algorithm is similar to reachability analysis but it is performed at the 
control level. 

Example 2. If one applies the previous algorithm for the specification and the 
feeds from Figure 2, one obtains the specification shown in Figure 3. The external 
input ci7pr{n) is uncovered by the feeds so its elimination induces the elimination 
of cl\p{n) and thus cnp{n) is no more covered by an internal output so it is 
eliminated together with br := f. 




j ci?sr([l,10]) 
I co!sa(*) 



ci?sr([l,10]) 



Fig. 3. Example slicing wrt feeds 



The slicing with respect to feeds preserves the synchronous product, that is, 
the following proposition holds. 

Proposition 1 (slicing wrt feeds correctness). Let SP = (S,C,P) be a 
specification, TP a test purpose and Sf a set of feeds which covers TP. The 
synchronous products between the models of SP and respectively SP \j Ej 
with the test purpose TP, given the feeds Ef are strongly bisimilar. That is, 
n(^, TP, Ef) ~ TP, Ef). 



3.2 Relevant Variables Analysis 

This calculus is an extension of live variable analysis [4]. It attempts to compute, 
for each process, the set of relevant variables in each state. The relevance is 
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defined with respect to test purpose outputs: a variable will be relevant in a 
state if its value at that state might be used to compute the parameter value of 
some signal output occurring in the test purpose. Or, similar to the live variables 
definition, we consider a variable to be relevant in a state if and only if there 
exists a path starting at that state such that the variable is used before being 
redefined on the path. But, in our case, we consider a variable to be used only in 
external outputs mentioned by the test purpose, or in assignments (eventually 
via internal inputs) to relevant variables. 

Definition 7 (relevant variables wrt outputs). Let SP = (S,C,P) be a 
specification and TP = he a test purpose. Let So be the 

set of signal outputs mentioned in the test purpose. The relevant variables are 
defined for each process p = {Xp, Qp, Tp, q^) G P by a function Rlvp : Qp 
mapping states to subsets of variables. The sets Rlvp{qp) for states qp € Qp are 
defined as the least fixed point of the following equation system: 

Rlvp(qp) = Rlv{q'p) \ Defp{tp) UUsep{tp) 

where 



Defpitp) = 



( {a;} 



[b\x-.=e 
^f tp = qp > qp 

[b]c?s(x) 

or tp = qp > qp 



( 0 otherwise 



Usep{tp) = 

vars{b) U vars(e) 

iftp = ond X G Rlvp{q'p) 

[6]c!s(e) 

or tp = qp — > Pp and 
* c G C®®* and 3qtp‘^^^ q'^p G Ttp or 

c G C*”* and € Tr and 

X G RlVr{q'r) 

^ vars{b) otherwise 



The relevant variables are computed simultaneously for all processes. The 
algorithm operates in a backward manner on the control graphs. It starts with 
empty sets of variables for each state, and at each step one transition is analyzed: 
the set of used variables is recomputed in the current context and then, the 
relevant variables set for the source state is updated. The algorithms ends when 
the least fixed point is reached and no more change in the relevance sets occurs 
for any of the transitions. 

For this analysis too, we notice that the relevance of variables is propagated 
interprocesses. In fact, variables used in expressions sent through internal chan- 
nels will become relevant only if, at the destination side their value is further 
relevant. 

The slicing with respect to relevant variables attempts to reduce the num- 
ber of variables used inside processes. Concretely, we cut off all the definitions 
assigning irrelevant variables. Irrelevant variables used in inputs are replaced by 
some special, don’t care, variable T. Finally, expressions occurring in unused 
outputs are replaced by the undefined value T. This transformation is formally 
described below. 
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Definition 8 (slicing wrt outputs). Let SP = {S,C,P) be a speeifieation 
and TP be a test purpose. We define the slice of the specification SP given 
the relevant variables computed wrt outputs to be the specification SP \o So = 
{S,C,P \o So), where P \o So contains a sliced process p' for each process 
p G P. The slice for a process p = (Xp,Qp,Tp,qp) is defined as a process 
p' = (Xp,Qp,Tp,qp) which has the same set of states and the same initial state, 
but operates only on relevant variables. We put Xp = UgpGQp tran- 

sitions Tp are constructed from Tp such that they do not more define irrelevant 
variables : 



X G RlVp{q'p) 



Qp 



g T' 



p ^ 



X ^ Rlvp{q'p) 

[W , ^ rj,, 

gp % G ^p 



[b]c?s(a:) 

gp — ' gp 2; e RlVp[qp) 



gp 






P P 



[h]c?s(x) 

gp ' gp * ^ RlVpiqp) 



gp 



e TL 



p p 



[fc]c!s(e) 

gp — ^ gp Use{ds) 



gp 



iW'Ae) ^ 



P P 



[h]c!s(e) 7-r / I \ 

gp — *■ gp ^Use{c\s) 



gp 



g T' 



p ^ ^p 



where Use(cls) = 3qtp - — > q'^p G Ttp or ^ 
denote the global utility of outputs of the form c\s. 



(x) 



G Tr and x G Rlvr{q'r) 



Example 3. The slicing wrt outputs algorithm, applied for the specification and 
the test purpose from Figure 3, produces the specification shown in Figure 4. 
The transitions labeled y '.= 1 and y := y*i are relabeled with r and the output 
co\pa{y) become co!pa(T) because -^Use{co\pa). 

Intuitively, the slicing wrt relevant outputs preserves the model of the speci- 
fication up to concrete values carried by signals notjAserved in the test purpose. 
We define the renaming of the specification model SP with respect to the set of 
output actions So in the following way: each visible output action c!s(f) which 
is not specified by the test purpose i.e., c!s(*) ^ Xo, is renamed into c!s(T). The 
other actions are left unchanged. In this way, we left out the exact parameter 
values for outputs, other than ones occurring in the test purpose. We note the 
renamed model with SP [ Eg. The following proposition holds. 

Proposition 2 (slicing wrt outputs correctness). Let SP = (S,C,P) be 
a specification and TP = (Qtp, Itp, Q““). The model of SP renamed with 
respect to the observable outputs Eg and respectively the model of SP \o Eg are 
strongly bisimilar, that is, SP J, Ho ~ SP \o Eg. 

A final remark concerns a more general utility of relevant variables. In fact, 
we tried here to exploit them at a purely syntactic level e.g., by eliminating 
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the irrelevant ones and their dependencies in the specification. However, it is 
possible to take them into account in a deeper manner. For instance, using a 
technique similar to [4], one can reinitialize them with a default value as soon 
as they become irrelevant, thereby achieving a bisimilar reduced model. 

3.3 Constraint Propagation 

This section provides an approach to simplify the specification, using the con- 
straints imposed on the feeds and the inputs of the test purpose. First, these 
constraints will be attached to possible matching inputs. Then, by using some in- 
tra/interprocesses data flow analysis algorithms, the constraints are propagated 
in the specification. Thus, for each control state, a conservative approximation 
of the set of possible values for each variable is computed. Finally, this informa- 
tion is used to evaluate the transitions guards and to eliminate those ones never 
fir able. 

In the following we will sketch the constraint propagation problem and how 
to solve it. It is a data flow analysis problem whose basic components are : 

1. the flow graph is composed of the states and the transitions of each process 

and some auxiliary constructions in order to simulate the internal queues, 

2. the complete powerset lattice of D, the constraints being some of its elements, 

3. the class of transfer functions Transfer for each transition tp. 

4. the confluence functions [J, one for each state. 

Let us observe that by choosing the constraints to be the elements of 2^ we 
have ensured the possibility of testing the emptiness of a constraint and also the 
possibility of having a partial order among them. 

In order to define the transfer functions for transitions, one has to ensure 
that the actions of transitions (assignments and arithmetic operations) can be 
realized with constraints (that is, with set of values of D instead of only one 
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value of D). This requirement is fulfilled by defining the operations with set of 
values similarly as in the interval arithmetic [19]. 

Having seen what are the basic requirements and an approach to fulfill them, 
the definition of constraint propagation problem follows below. 

Definition 9 (constraint propagation). Let SP = {S,C,P) be the specifi- 
cation and Ef the set of feeds. Constraints are represented, for each process, 
as a function Val : Qp — *■ 2^. With the notations presented before, the con- 
straint propagation problem is defined as finding the least fix point solution of 
the following equation system: 

Vo.l{q'p) = Transfer ^^{Val{qp)) 

In order to solve this problem we have considered the cases where constraints 
are expressed by means of constants and by integer intervals. This is due to the 
fact that in ttcn [12] the constraints have this kind of simple forms. The formal 
framework defined above is applicable in these cases, using the Galois connection, 
a classical abstract interpretation technique [8]. 

The algorithm used for solving the constraint propagation problem in the 
case of the lattice of constants is the classical iterative algorithm from [16] with 
an interprocesses variant such as [9]. In the case of the integer intervals lattice, 
due to the fact that it has infinite height, we use for each process a widening 
technique as in [3]. 

The results of the constraint propagation problem are used in simplifying 
the specification by means of slicing. However, they also allow, for the outgoing 
output transitions of a control state, to have a conservative approximation of the 
parameters of the signals, thereby enabling generation of symbolic test cases. 

Definition 10 (slicing wrt constraints). Let SP = {S,C,P) be a specifica- 
tion and Ef a set of feeds. We define the slice of the specification SP given the 
constraints computed wrt feeds to be the specification SP\cEf = (S,C,P\cEf), 
where P \c Ef contains a sliced process p' for each process p € P. The slice 
for a process p = {Xp,Qp,Tp,q^) is defined as a process p' = (Xp,Qp,Tp,qp), 
which operates on the same set of variables Xp. The sets of states Qp C Qp and 
transitions T'p C Tp are the smallest ones which satisfy the following rules: 

qp GQptp = qp-^q'p Transfer ^^{Valp{qp)) yf 0 
qp ^ Qp q'p G Qp tp = qp — >q'p G Tf 

Example 4- The slicing wrt constraints algorithm, applied for the specification 
and the test purpose from Figure 4, produces the specification shown in Figure 5. 
The value t for br is propagated to the source state of the transition with the 
guard [^br] and thus determining that this transition and the following co!pa(T) 
will be never fired. These transitions are detached from the specification. The 
constraint propagation problem, in this case, given the feed ci?sr{[l, 10]), pro- 
vides for the parameter x in the transition co\sa{x) the interval [1, 100]. 



Using Static Analysis to Improve Automatic Test Generation 247 









1 ci?sr([l,10]) 
1 co!sa(*) 




ci?sr([l,10]) 




J 




Fig. 5. Example slicing wrt constraints 
We have the following preservation result. 

Proposition 3 (slicing wrt constraints correctness). Let SP = (S,C,P) 
be a specifieation, TP = (Qtp,Ttp,qtpiQtp^) Sf a set of feeds which 

cover TP. The synchronous product between the models of SP and respectively 
SP \c with the test purpose given the feeds Sj are strongly bisimilar, that is 

msp, TP, Sf) ~ TP, Sf) 



4 Experimentation 

These techniques were implemented and currently we are experimenting with 
them on some case studies. We use the if [5] framework, which is an interme- 
diate program representation for protocols, based on asynchronously communi- 
cating timed automata, if was designed right from the beginning to support the 
application of static analysis techniques used in compiler optimization [1,17]. 

The techniques presented before were applied to improve test case generation 
for the SSCOP protocol [6], a layer from the ATM protocols stack. Previous work 
was already done on it in the context of the FORMA research action [6] and 
despite its success, it shows also the limitations of the existing test generation 
technology. We were interested to see what are the concrete benefits of our add- 
ons. 

We started with an SDL version of the protocol provided by CNET France 
Telecom. It is about 2000 lines of code which describes the whole protocol as 
a single SDL process. It was translated into an if extended automaton, with 
1075 states, 1291 transitions and 134 variables. We considered 10 test purposes 
conceived for different phases of the protocol (connection, data transmission). 
The results obtained using previous analysis are summarized below: 

slicing wrt feeds: By carefully choosing the appropriate set of feeds for each 

test purpose, we obtained reductions up to 80% of the specification. That is. 
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we started usually with the smallest set of feeds covering the test purpose in- 
puts. This choice is often too restrictive i.e., test cases cannot be constructed 
from the model of sliced specification. Thus, we iteratively added other in- 
puts to the feeds until the model became sufficiently large to cover the test 
purpose behavior. In this way, we are able to work on some minimal version 
of the specification, still allowing the generation of test cases, 
slicing wrt outputs: This analysis gives very good results too. When applied 
on the sliced specification wrt to feeds, it reduces the number of variables up 
to 40%. More generally, for the SSCOP protocol we obtained, in average, that, 
from total number of variables, 30% are relevant with respect to outputs, 
while the maximum reaches 60%. Also, when used at the model generation 
time, the relevant variables still allow important reductions on the number 
of model states and transitions. 

constraint propagation: The constraint propagation is still under develop- 
ment. At this time, we experimented only the constant propagation algo- 
rithm. The results obtained are good, mainly when the test purpose and the 
feeds contains punctual constraints i.e., the values provided in test purpose 
inputs are fixed at some constants. We work currently to adapt the interval 
propagation algorithm. 

These results are very encouraging. However, given the particular nature 
of the SSCOP protocol, we need further experimentations to clearly set up our 
techniques. We will consider experimentations for interprocesses slicing and the 
interaction between the three slicing techniques. 

5 Conclusion and Future Work 

In this paper, we show that automatic test generation can take advantages of 
static analysis. Our test generation method, derived from the so-called on the fly 
model checking, consists in traversing a product defined between the specification 
and the test purpose. Before test generation, simplifications may be made on the 
specification, by collecting informations on the test purposes. 

Our general approach to define static analysis is based on the following 
considerations and remarks. The specification is a set of extended automata, 
asynchronously communicating via a set of queues. The test purpose is also an 
extended automaton with constraints. In the context of test generation, we dis- 
tinguish between inputs and outputs. The static analysis we define transform 
specifications into others, smaller ones, without loss of information with respect 
to test purpose. This approach is compatible with the standard definition of 
conformance testing. 

In this work, we proposed three kinds of slicing, based on different analysis. 
The first one consists in restricting each automaton, starting from the set of feeds. 
It includes the propagation through the dependence relation between the input 
of a process and the outputs of the others process. The second analysis computes 
the set of variables, necessary to determine values occurring into the outputs, 
and safely discards the others. The last analysis is the constraint propagation. 
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We have shown that the combination of these three interprocesses analyses 
may reduce the specification. We have implemented these analysis in the context 
of IF tools and we obtain very good results on the SSCOP protocol. 

Our results can be further extended in several directions. Firstly, we aim at 
experimenting more systematically the static analysis in the context of test case 
generation for industrial protocols. The results on SSCOP were very encouraging 
but other experimentations are further needed to conclude the practical use of 
our techniques. 

At short term too, we plan to extend these analysis techniques to work on 
timed specifications. In fact, the generated test cases usually uses timers, which 
are set and test to more or less arbitrarily values in order to observe deadlocks 
or livelocks in the implementation. However, a more fine analysis can be done 
on timed specifications to obtain relevant values to be used in this context. 

A more speculative direction concerns the generation of symbolic tests. In 
this respect, we are currently thinking about the appropriate extension for the 
test purposes concept. For instance, the explicit use of variables in addition 
to constraints can make them much more expressive. Furthermore, it may be 
interesting to reconsider the definition of the synchronous product i.e., to be 
done at a higher level in such a way that it will allow the derivation of symbolic 
test cases. 
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Abstract. Boolean Equation Systems (Bess) provide a useful frame- 
work for the verification of concurrent finite-state systems. In practice, 
it is desirable that a Bes resolution also yields diagnostic information ex- 
plaining, preferably in a concise way, the truth value computed for a given 
variable of the Bes. Using a representation of Bess as extended boolean 
graphs (Ebgs), we propose a characterization of full diagnostics (i.e., 
both examples and counterexamples) as a particular class of subgraphs 
of the Ebg associated to a Bes. We provide algorithms that compute ex- 
amples and counterexamples In linear time and can be straightforwardly 
used to extend known (global or local) Bes resolution algorithms with 
diagnostic generation facilities. 



1 Introduction 

It is well-known that several equivalence/preorder checking and temporal logic 
model-checking problems occurring in the verification of concurrent finite-state 
systems can be reduced to the resolution of Boolean Equation Systems (Bess). 
Various algorithms have been proposed for solving this problem, either globally, 
i.e., by computing the values of all variables in a Bes [3,9,28,1,29,2,20,19], or 
locally, i.e., by computing the value of a single variable [17,1,29,30,20,18,19]. 
However, practical applications of Bes resolution often need more detailed feed- 
back than a simple yes/no answer. For instance, when solving a Bes encoding 
the bisimilarity check between two transition systems, it is desirable to have, 
in case of a negative result, a diagnostic (e.g., a transition sequence) explaining 
why the two systems are not bisimilar. 

In general, both positive diagnostics (examples) and negative diagnostics 
(counterexamples) are needed in order to be capable of fully explaining the truth 
value of a boolean variable. This is the case for instance when verifying Ctl [5] 
formulas over a transition system: a positive answer obtained for an E [T U (p\ 
formula should be explained by an example (e.g., a transition sequence leading to 
a :/J-state), whereas a negative answer obtained for an A [T U ip] formula should be 
explained by a counterexample (e.g., a transition sequence leading to a deadlock 
or to a circuit without reaching a :p-state). 

The problem of generating diagnostics for finite-state verification has been 
studied using various approaches. Explicit state enumeration techniques have 
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been applied to compute diagnostics for bisimulation/preorder checking [8,15,13] 
and Ctl model-checking [5,23], in tools like Aldebaran [4] and Emc [5], respec- 
tively. Symbolic techniques based on (ordered) binary decision diagrams have 
been used to generate examples (witnesses) and counterexamples for Ctl for- 
mulas [7,6], in tools like Smv [21]. Recently, game-based techniques [25] have 
been applied to verify modal ^-calculus [16] formulas and to interactively gen- 
erate diagnostics, in tools like the Edinburgh Concurrency Workbench [24]. 

In this paper we address the problem of characterizing and computing full 
diagnostics (examples and counterexamples) for Bess. We focus on single fixed 
point Bess, which allow to encode the alternation-free fragment of the modal 
^-calculus [9], and attempt to devise efficient algorithms handling this case. 
The solutions that we propose can be easily instantiated in order to obtain 
diagnostic generation facilities for particular verification problems reducible to 
Bes resolution, such as bisimulation/preorder checking and model-checking of 
branching-time temporal logics like Ctl. 

We use a representation of Bess as extended boolean graphs (Ebgs), which 
allow to define an appropriate subgraph relation between Ebgs. We start by 
characterizing the solution of a Bes by means of two particular temporal logic 
formulas Ex and Cx interpreted on the corresponding Ebg. This allows, on 
one hand, to reduce the problem of solving a Bes to the problem of verifying 
these formulas over its Ebg and, on the other hand, to characterize minimal 
diagnostics (w.r.t. the subgraph relation) as particular models of Ex or Cx. We 
also propose two efficient (linear-time) algorithms for computing minimal exam- 
ples and counterexamples and we indicate how they can be used in conjunction 
with existing (global or local) Bes resolution algorithms. Our characterizations 
of minimal examples and counterexamples turned out to be very similar to the 
winning strategies for player I and player II of a model-checking game [24] . How- 
ever, as far as we know, there is no equivalent linear-time complexity result about 
the game-based algorithms applied to the alternation- free /i-calculus. 

The paper is organized as follows. Section 2 defines Bess and their associated 
Ebgs, and gives a characterization of the Bes solution using temporal formulas. 
Section 3 defines diagnostics in terms of subgraphs of an Ebg and provides a 
characterization of minimal diagnostics. Section 4 presents algorithms for com- 
puting minimal examples and counterexamples. Finally, Section 5 shows some 
practical applications of these results and indicates directions for future work. 



2 BESs and Extended Boolean Graphs 

A boolean equation system (Bes) M is a set of fixed point equations whose left- 
hand-sides are boolean variables and whose right-hand-sides are pure disjunctive 
or conjunctive formulas (see Figure 1). Empty disjunctions and conjunctions are 
equivalent to F and T, respectively. Variables {xi , ..., x„} are bound and variables 
in (Ui<i<ra-^j) \ {xiT--,Xn} are free in M. A Bes is closed if it has no free 
variables. In the sequel, we consider only minimal fixed point Bess (ct = /r), the 
formalization for maximal fixed point Bess being completely dual. 
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Syntax of Boolean Equation Systems (Bess): 

M = {Xi = OPiXi}l<i<n 

where cr G {p, v}, Xi € X, op^ £ {V, A}, Xi C A" for all 1 < i < n 

Semantics w.r.t. Bool = {F, T} and a context 5 \ X ^ Bool: 

\op{x\, ...,Xk}\5 = S{xi) op ... op 5{xk) 

[M] 5 = 

where : Bool" ^ Bool", 9s{hT_, ..., 6„) = {\oPiXi\ 5[bi/xi, ..., 6n/®n])i<i<„ 



Fig. 1. Syntax and semantics of Boolean Equation Systems 



An extended boolean graph (Ebg) is a tuple G = {V., E, L, F), where: V is 
the set of vertices; E C V x V is the set of edges; L : V — > {V,A} is the vertex 
labeling; and F CV is the frontier of G. The notion of frontier will be useful later 
for defining a suitable subgraph relation between Ebgs (see Section 3). The sets 
of successors and predecessors of a vertex x £ V are noted E{x) and E~^{x), 
respectively. The set of vertices reachable from x via E is noted E*(x). The 
restriction of if to a subset U G V is defined as E\jj = {{x,y) € E \ x £ U}. 
Every Ebg G induces a Kripke structure G = {V,E,L). A closed Bes can be 
represented by an Ebg, where V denotes the set of boolean variables, E denotes 
the dependencies between variables, and L labels the vertices as disjunctive or 
conjunctive according to the operator in the corresponding equation of the Bes. 

We can characterize the solution of a closed Bes using temporal logic for- 
mulas interpreted over the Kripke structure induced by the corresponding Ebg. 
The logic we use (see Figure 2) is a variant of the alternation-free /r-calculus [10]. 



Syntax of temporal formulas: 

ifi ::= Pv I Pa I (pi V I ¥^1 A </J2 I (-) I [-] I T I gY.ip \ uY.ip 
where Y £ y 

Semantics w.r.t. a Kripke structure G = {V, E, L) and a context p -.y —> 2^ : 
[PvIgP = {x£V\ L{x) = V} 

I-PaIgP = {x £V \ L{x) = A} 

{ifi V ¥>2]IgP = \vi\gP^Vp4gP 
Ipi a ¥^2]gP = Ipi\gP^ VP2\gP 
I(-) <p1gP = {x£V \ E{x) n {p\gP + 0} 

[[-] <p1gP = {x£V \ E{x) C MgP} 
lYj^p = p{Y) 

IpY.pi^p = f]{U^V\ -^Gp(P) C U} 
luY.pj^p = [j{U£V\U£ <?Gp(P)} 
where d>Gp : 2^ ^ 2'", <?Gp(P) = MgP[U/Y] 



Fig. 2. Syntax and semantics of the logic for diagnostic characterization 
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Given a Kripke structure G = {V,E,L), the two atomic propositions Pv 
and Pa denote the disjunctive and conjunctive vertices of V, respectively. The 
boolean operators V and A have their usual semantics. The possibility and ne- 
cessity modal formulas (— ) (p and [— ] (p denote the vertices for which some (all) 
successors satisfy p. The fixed point formulas pY.p and lyY.p denote the minimal 
and maximal solutions (over 2^) of the equation Y = p, respectively. Formulas 
p are assumed to be alternation-free (without mutual recursion between mini- 
mal and maximal fixed points). A vertex x G V satisfies a formula (/? in G, noted 
X |=G p/Yi X G |<p]q. G is a p-model iSV= 

The two particular formulas defined below will be useful in the sequel. 

Definition 1 (example and counterexample formulas). 

The formulas Ex and Cx defined as follows: 

Ex = AiT.(Pv A (-) Y) V (Pa A [-] Y) 

Cx = j.y.(Pv A [-] Y) V (Pa A (-) Y) 

are called example formula and counterexample formula, respectively. 

Since Ex and Cx are complementary (Ex V Cx = T and Ex A Cx = F), 
their interpretations on a Kripke structure G = (E, P, L) associated to a closed 
Bes induce a partition of V. The following theorem states that this partition 
corresponds exactly to the true and false variables in the Bes solution. 

Theorem 1 (characterization of BES solution). 

Let M = {xi = he a closed Bes and let G = (V^E,L) be its 

associated Kripke structure. Then: 

\M\^ = T Xi |=G Ex 

for all 1 < i < n. 

Theorem 1 can be easily extended to alternation-free Bess, whose solution 
can be characterized using an alternation-free ^-calculus formula containing an 
Ex-subformula for each single fixed point subsystem^ of the Bes. The equiva- 
lence between alternation-free Bess and alternation- free /i-calculus formulas has 
been extensively studied in [20]. Together with the classical results of reducing 
^-calculus model-checking to Bes resolution [9,1], Theorem 1 provides another 
proof of this equivalence. 

In the following, we will develop the formalization of diagnostics by reasoning 
exclusively in terms of Ebgs associated to Bess and the interpretations of Ex 
and Cx formulas on the corresponding Kripke structures. 

3 Examples and Counterexamples 

Consider a Bes M and a boolean variable x that is bound in M . What would 
be a diagnostic for x? From the Bes point of view, a diagnostic for x could be a 



^ For i/-subsystems, the formula Ex = vY.{P\j A {—) Y) V (Pa A [— ] Y) must be used. 
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subsystem M' of M containing a; as a bound variable and having the property 
that by solving M' one obtains for x the same truth value as by solving M. 
In other words, the value computed for x in M' should not depend upon the 
context of M' imposed by M (i.e., upon the values of variables that are free 
in M' and bound in M); that is, it should not depend upon any context of M' . 

Figure 3 shows a Bes and its associated Ebg, where black vertices denote 
variables that are T and white vertices denote variables that are F in the Bes so- 
lution. According to the informal definition above, a “diagnostic” showing why Xq 
is T (an “example” for xq) would be, for instance, the subsystem defining the 
variables {xq, xi, a;2, 2:3, 14}, whose vertices are surrounded by a dotted box in 
the Ebg. Similarly, a “diagnostic” showing why X5 is F (a “counterexample” 
for xs) would be the other subsystem {xs, Xq, X7, xs, Xg} outlined in the figure. 
It is easy to see that these two subsystems can be solved individually and the 
truth values obtained in this way for xg and xg are the same as those obtained 
by solving the whole system. 



XQ = XI A X 4 
XI = X2 V X 3 V X5 
X2 = Xg A X\ 

^ -r 

X3 = T 

M 

/ X4 = X\\/ Xgy X7 

X5 = X6 A xg 
xg = X3 A X7 
X7 = Xg A Xg 
xg = X 4 Axg A xg 

^ I- 

,2^9 = F 




Fig. 3. A closed Bes and its associated Ebg 



In general, for a given variable of a Bes there can be several subsystems 
having the property above (an obvious one being the Bes itself). For in- 
stance, the reader may check that for the Bes on Figure 3, the subsystems 
{xo,xi,X2,X3,X4,xe,X7,xg} and {x3,X4,X5,XQ,X7,xg,xg} can also be consid- 
ered as “diagnostics” for the variables xq and xg, respectively. 

From the Ebg point of view (and using Theorem 1 ), a diagnostic for a ver- 
tex X of an Ebg Gg would be a subgraph Gi of Gg containing x and having the 
property that x (=Gi Ex iff x ^02 Ex. A suitable subgraph relation between 
Ebgs can be defined using the notion of frontier. Intuitively, the frontier of a 
subgraph Gi contains all vertices starting at which new edges can be added 
when Gi is embedded in another graph Gg (note that Gg may have the same 
vertices as Gi, but more edges). To obtain a correct subgraph relation, the no- 
tion of frontier must be intrinsic to an Ebg: therefore, when embedding Gi 
in G2, the frontier of Gg must not contain vertices of Gi which are not already 
in the frontier of Gi. The frontier of an Ebg that is not meant to be embedded 
in another one (e.g., an Ebg associated to a closed Bes) is empty. 
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Definition 2 (subgraph of an EBG). 

Let G\ = (Vi, El, Li, Fi) and G2 = {V2, E2, L2, F2) be two Ebgs. Gi is a sub- 
graph of G2, written G\ ^ G2, iff the following eonditions hold: 

— Vi C V2 and F2 n El C Fi ; 

— El C F2 and {E2 \ Ei)|y^ = {E2 \ Ei)|p.y- 

— Ll = L2\y^. 

It is easy to check that ^ is a partial order relation on Ebgs. For the Ebg on 
Figure 3 , the subgraphs enclosed in the left and right dotted boxes have the 
frontiers {xi,xf\ and {xe, X7, sg}, respectively. 

The two definitions below precise the notion of diagnostics in terms of Ebgs. 

Definition 3 (solution-closed EBG). 

An Ebg Gi = (Ei, Ei, Li, Fi) is solution-closed iff, for any Ebg G2 = 
(E2, E2, E2, E2) such that Gi ^ G2: 



or, equivalently: 



[ExIg, = IExIg, n El 



ICxIg, = ICxIg, n El 

where Gi and G2 are the Kripke structures associated to G\ and G2. 



Definition 4 (examples and counterexamples). 

Let G = {V,E,L,F) he an Ebg, G its associated Kripke structure, and x gV. 
A diagnostic for x is a solution-closed subgraph of G containing x. A diagnostic 
for X is called example if x Ex and counterexample if x ^g Cx. 



The following theorem provides a characterization of solution-closed 
Ebgs that will be useful in the sequel. Intuitively, an Ebg G is solution-closed 
if the satisfaction of Ex (or Cx) on its frontier (which contains the only vertices 
of G that may directly depend on some external context when G is embedded 
in another Ebg) can be completely decided using only the information in G. 

Theorem 2 (characterization of solution-closed EBGs). 

Let G = (V, E, L, F) be an Ebg. G is solution-closed iff: 



F C |(Ev A Ex) V (Pa a Cx)]^. 
where G is the Kripke structure associated to G. 



Using Theorem 2 , we can easily see that the left and right subgraphs of the 
Ebg outlined on Figure 3 are solution-closed (i.e., they are diagnostics for xq 
and X5). The same holds for the subgraphs corresponding to the other two sub- 
systems {xq, xi, X2, X3, X4, xe, X7, xg} and {xg, X4, xg, xg, X7, xg, xg} having the 
frontiers {xi,xg} and {X4}. However, in practice it is desirable to explain the 
value of a variable in a concise manner, and therefore diagnostics should be as 
small as possible. The following theorem states that minimal diagnostics (w.r.t. 
^) can be obtained as particular Ex-models or Cx-models. 
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Theorem 3 (characterization of minimal diagnostics). 

Let G = (y, E, L, F) he an example for x £ V and G its assoeiated Kripke 
strueture. G is minimal (w.r.t. <) iff the following eonditions hold: 

a) G is an Ex-model; 

b) \/y e V.L{y) = V ^ \E(y) \ = 1; 

c) V = E*{x); 

d) F = {y£V\L{y) = \/}. 

The same holds for minimal counterexamples (replacing Ex by Cx and V by A). 

The characterization provided by Theorem 3 is sufficiently concrete to allow 
the design of efficient algorithms for generating minimal diagnostics. 



4 Diagnostic Generation Algorithms 

We give in this section algorithms for efficiently computing minimal examples 
and counterexamples for a given variable of an Ebg G by exploring the Kripke 
structure G induced by G. These algorithms exploit the information in |Ex]q 
and |Cx]q and therefore they must rely upon a resolution algorithm that first 
computes the semantics of Ex (or Cx) on G. We start by giving a global reso- 
lution algorithm and then we present our diagnostic generation algorithms. 



4.1 Global Resolution Revisited 

The global resolution algorithm Solve that we consider here (see Figure 4) is a 
slightly extended version of the global graph-based algorithm given in [1]. The 
pre- and post-conditions and the invariants of the while-loop are enclosed in 
rectangular boxes on Figure 4. The Solve procedure takes as input a Kripke 
structure G = (V,E,L) induced by an Ebg G and computes two informations 
for the vertices x £ V: a. natural value c{x) such that c(x) = 0 iff x £ [ExJ^; 
and (only for V-vertices x £ |Ex]q) a successor s(x) £ E(x) such that there is 
no path from s(x) to x passing only through vertices in |Ex]q. 

It is a straightforward exercise to check the validity of the Ii and I2 invariants 
is the functional associated to Ex), which ensure that after termination of 
Solve the vertices in |Ex]q will have c(x) = 0. Here we expressed Ii and I 2 in 
terms of Ex (we could have done this equivalently in terms of Cx) . In the light 
of Theorem 1, we see that Solve is in fact a model-checking algorithm for Ex. 
This holds also for other global Bes resolution algorithms [3,9,28,30]. 

Invariant I3 ensures that after termination of Solve, all the V-vertices x £ 
|Ex]q will have a successor s(x) £ |Ex]q such that the satisfaction of Ex by 
s(x) does not depend upon x. As we will see in the next section, the computation 
of s is necessary to obtain an efficient algorithm for generating minimal examples. 

Figure 5 shows the result of executing Solve on the Ebg previously con- 
sidered on Figure 3. Vertices x for which c(x) = 0 are black and the others are 
white. Edges (a;, s(a;)) are drawn as thick arrows. 
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G = {V, E, L) 

procedure Solve (V^, E, L) is 

forall X G V do 

c{x) := if L{x) = A then \E{x)\ else 1 endif 
end; 

A := {x G V \ c{x) = 0}; 

while A 7 ^ 0 do 
let y G A\ 

A := A\{y}- 
forall 2 e E~^{y) do 
if c{z) > 0 then 
c{z) := c{z) - 1; 
if c{z) = 0 then 
A ■- Au {z}\ 
if L{z) = V then 
s{z) := y 
endif 
endif 
endif 
end 
end 
end 



Ii A I2 A I3 



{xGV\ c(x) = 0} = [ExJe A 

{{x,y) G E \ x,y G |Ex|q A (L{x) = V j/ = s(a;))} is acyclic 



Ii : ({a; G V | c(x) = 0} \ A) = G E | c(x) = 0} 

12-.{XGV\ c(x) = 0} C y-Pl- = IEx]q 

I 3 : {{x,y) G E I c{x) = c(y) = 0 A (L(x) = V ^ y = s(a:))} is acyclic 



Fig. 4. Extended global resolution algorithm 




Fig. 5 . Computation of c and s by Solve 
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One can easily adapt other global Bes resolution algorithms like those 
in [3,9,28,30] in order to perform the computation of s. Moreover, we claim 
that local algorithms like those in [1,29,19] can be adapted as well, since they 
function by exploring forwards the boolean graph and by propagating backwards 
the vertices found to be true (which is done in a way similar to the Solve al- 
gorithm above). In fact, it can be shown that these local algorithms actually 
compute solution-closed subgraphs containing the boolean variable of interest. 



4.2 Generation of Minimal Examples 

The algorithm ExSearch that we propose for computing minimal examples 
(see Figure 6) takes as input a Kripke structure G = (V, E, L) induced by an 
Ebg G, a vertex x S |Ex]q, and for every V-vertex y S |Ex]q a successor s{y) 
as computed by the Solve algorithm given in Section 4.1. 



G={V,E,L)Axe [Ex]qA 

R = {(Vy z) € E \ y,z € [Ex|q a (L(y) = y ^ z = s{y))} is acyclic 



procedure ExSearch { x , {V, E, L), s) is 
Fo := {*}; Eo ~ 0; A ~ {a;}; 
while 4 7^ 0 do 
let y £ A\ 

A := 4\{i/}; 
if L{y) = V then 

Eo ■- EoU {{y,s{y))}- 
if s{y) ^ Vo then 

Vo := Vo U {s(j/)}; A-.= Au {s{y)} 
endif 
else 

forall 2 G E{y) do 
Eo ■- Eo U {{y,z)}-, 
if 2 ^ Fo then 

Fo — FoU{2}; a := 4u{2} 



Ji A J2 A J3 



endif 

end 

endif 

end 

end 



Go = (Fo, Eo, L\vgy {y £ kb I L{y) = V}) is a minimal example for x 



Jr:3fc>0.(FoCUto'^f4.K„.L|,„;(^)) 

J2 : Eo = R\y^ 

J3 : Fo = E^{x) 



Fig. 6. Minimal example generation algorithm 
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ExSearch iteratively accumulates in Vq all the vertices in |Ex]q that are 
reachable from x by traversing only edges (y, s{y)) if L{y) = V and edges (y, z) € 
E if L(y) = A. All traversed edges are accumulated in Eq. 

Invariant J i (ensured by the properties of s) implies that after termination of 
ExSearch, Go = (Vq, Eg, L\y^) is an Ex-model. Indeed, at the end of the while- 

loop A = 0 and thus Vg C Ui>o^Go*(®) = = P^Igo — Invariant J2 

implies that all V-vertices y G Vg have only one successor (namely s(y)), and 
invariant J3 implies that all vertices in Vg are reachable from x via Eg. Gg being 
an Ex-model, Theorem 2 ensures that Gg is solution-closed, i.e., it is an example 
for X. Moreover, Gg meets the conditions of Theorem 3 and thus it is minimal. 

Figure 7 shows a minimal example Go computed by ExSearch for the vari- 
able xg in the Ebg considered earlier on Figure 5. The edges in Eg are drawn as 
thick arrows and the vertices on the frontier of Gg are surrounded by dashed cir- 
cles. The V-vertices x\ and X 4 have in Eg a unique successor s(a;i) = s(a;4) = xg 
that was previously computed by Solve. 




Fig. 7. A minimal example for xg computed by ExSearch 



Note that the use of the information in s is crucial for ensuring the correctness 
of ExSearch: if we chose for x\ the successor X 2 instead of xg, the algorithm 
would compute the subgraph Gg outlined on Figure 8, which is not an example 
for Xg because xg ^Go Cx. A correct version of ExSearch that does not use s 
would require a backtracking graph search algorithm in order to determine the 
“good” successor for each V- vertex of the example. It is not obvious how to 
obtain a linear-time algorithm for computing minimal examples in this way. 




Fig. 8. An erroneous example for xg computed in absence of s 
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ExSearch has a complexity 0(|Vb| + |Eo|), since all vertices (edges) in the 
constructed example Gq are visited (traversed) only once. Since this is the lowest 
possible complexity for an algorithm that must entirely explore Go, it appears 
that (modulo the linear-time precomputation of s) ExSearch is an optimal al- 
gorithm for finding minimal examples. In practice, ExSearch runs very quickly 
when computing examples whose sizes are significantly smaller than |Ex]q (this 
happens for Ctl formulas like E [T U y)] ) . 



4.3 Generation of Minimal Counterexamples 

The algorithm CxSearch that we propose for computing minimal counterex- 
amples (see Figure 9) takes as input a Kripke structure G = (V,E,L) induced 
by an Ebg G, a vertex x G |Cx]q, and for every vertex y gV & counter c{y) as 
computed by the Solve algorithm given in Section 4.1. 



G = {V,E,L) Ax G ^ {y GV \ c{y) > 0} 

procedure CxSearch (x, {V , E, L), c) is 
Eo := {*}; Eo := 0; A ~ {*}; 

while 4 yf 0 do 
let y G A', 

A ■- A\{y}; 
if L{y) = A then 

let 2 G E{y) such that c{z) > 0; 

Eo ■- Eo U {{y,z)}-, 
if 2 ^ Vo then 

Eo := EoU{^}; A ■.= AU{z} 

endif 

else 

forall z G E{y) do 
Eo := Eo U {{y, z)}-, 
if 2 ^ Eo then 

Eo := Eo U {z}- 4 := T U {z} 

endif 

end 

endif 

end 

end 



Ki A K2 A K3 



Go = (Eo, Eo, L\vgj {y ^ Vb I L{y) = A}) is a minimal counterexample for x 



K2 : Vy G Eo \ A.{Liy) = A ^ |i^o(y)| = 1) A (L(y) = V ^ \Eo{y)\ = \E{y)\) 
K 3 : Eo = Eo*{x) 



Fig. 9. Minimal counterexample generation algorithm 
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CxSearch iteratively accumulates in Vq all the vertices in |Cx]q that are 
reachable from x by traversing either a single edge (y, z) £ E ii L(y) = A, or all 
edges (y, z) € E ii L{y) = V. All traversed edges are accumulated in Eq. 

Invariant Ki is the functional associated to Cx) ensures that after 

termination of CxSearch, Gq = {Vq, Eq, L\y^) is a Cx-model. Indeed, at the 
end of the while-loop A = 0 and thus Vq Q ^Go(^)- Tarski’s theorem [27], 
this implies Vq C = |Cx]q^ C Vq. Invariant K 2 implies that after the 

while-loop A- vertices of Vq have only one successor in Vq and V-vertices have all 
their successors in Vq. Invariant K 3 implies that all vertices in Vq are reachable 
from X via Eq. Since Gq is a Cx-model, Theorem 2 ensures that Gq is solution- 
closed, i.e., it is a counterexample for x. Moreover, Gq meets the conditions of 
Theorem 3 and thus it is minimal. 

Figure 10 shows a minimal counterexample Gq computed by CxSearch for 
the variable X 5 in the Ebg considered earlier on Figure 5. 




Fig. 10. A minimal counterexample for X 5 computed by CxSearch 



CxSearch has a complexity 0(|Vb| + I -Go I), since all vertices (edges) in the 
constructed counterexample Gq are visited (traversed) only once. Since this is 
the lowest possible complexity for an algorithm that must entirely explore Gq, 
CxSearch appears to be an optimal algorithm for finding minimal counterex- 
amples. In practice, CxSearch runs very quickly when computing counterexam- 
ples whose sizes are significantly smaller than |Cx]q (this happens for Ctl for- 
mulas like A [T U yj] ) . 



5 Conclusion and Future Work 

By representing a boolean equation system M as an extended boolean graph G, 
we characterized the solution of M by means of two particular alternation-free 
y-calculus formulas Ex and Cx interpreted on the Kripke structure G induced 
by G. This allowed to identify full diagnostics (examples and counterexamples) 
explaining the truth value of a boolean variable a; of M as being particular 
subgraphs of G containing x. Moreover, minimal examples and counterexamples 
(w.r.t. a subgraph relation that we defined) are obtained as particular models of 
Ex and Cx, respectively. 
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The temporal logic-based formalization that we proposed provides a uniform 
framework for analyzing graph-based Bes resolution algorithms such as those 
in [3,9,28,1,19]- For instance, in Section 4.1 we used our formalization to prove 
the correctness of a global resolution algorithm from [1], which can be seen in 
fact as an algorithm for checking the Ex formula on a boolean graph. 



We presented two linear-time algorithms ExSearch and CxSearch that 
compute minimal examples and counterexamples for a given variable of a Bes. 
We also indicated how these algorithms can be used to extend existing (global 
or local) Bes resolution algorithms with diagnostic generation facilities. 

These two algorithms have been included in the model- 

checker Evaluator version 3.0 that we developed as part of the 
Cadp (CjESAr/Aldebaran) protocol engineering toolset [11] using the generic 
Open/CjESAR environment for on-the-fly verification [14]. Evaluator 3.0 
performs on-the-fly model-checking of alternation-free /r-calculus formulas 
extended with regular expressions as in Pdl-Z\ [26]. The diagnostic generation 
facilities proved to be extremely useful in practice, as illustrated by the use of 
the model-checker by non-expert users and also for teaching purposes. Besides 
giving diagnostics for plain alternation-free /i-calculus formulas. Evaluator 3.0 
can be used to find regular execution sequences in labeled transition systems 
(as diagnostics for Pdl-Z\ formulas) and to produce full diagnostics for 
Ctl [-5] and Actl [22] formulas (by encoding the operators of these logics as 
macro-definitions in the input language of the tool). 



The ExSearch and CxSearch algorithms compute diagnostics that are 
minimal w.r.t. the Ebg subgraph relation that we proposed. The diagnostics 
obtained contain no redundant information, since every V-vertex in a minimal 
example and every A- vertex in a minimal counterexample has only one successor. 
This is reasonably good in practice, as confirmed by the experiments performed 
using Evaluator 3.0. However, there are other additional criteria that may be 
considered for further reducing the diagnostic size (e.g., minimizing the number 
of vertices, number of edges, depth, diameter, etc.). Some of these optimizations 
can be done efficiently in particular cases, e.g., generating minimal length tran- 
sition sequences as diagnostics for Pdl-Z\ diamond modalities or Ctl formulas 
E [T U <p] (which both translate into Bess containing only V operators in the non- 
trivial right-hand sides) . An interesting issue would be to investigate the general 
extension of ExSearch and CxSearch with such optimization features. 



We also plan to apply our diagnostic generation techniques in the context of 
bisimulation checking [9,2] and of test generation [12]. Another potentially fruit- 
ful direction of research is to extend our formalization to Bess of higher alter- 
nation depth [29,2,20,18]. The characterizations of the solution and diagnostics 
for these Bess would certainly require formulas of the full modal /r-calculus. 
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Abstract. Gompositional generation is an incremental technique for 
generating a rednced labelled transition system representing the be- 
haviour of a set of communicating processes. In particular, since inter- 
mediate reductions can be performed after each generation step, the 
size of the Lts can be kept small and state-explosion can be avoided in 
many cases. This paper deals with compositional generation in presence 
of asynchronous communications via shared buffers. More precisely, we 
show how partial-order reduction techniques can be used in this context 
to define equivalence relations: that preserve useful properties, are con- 
gruence w.r.t asynchronous composition, and rely on a (syntactic) notion 
of preorder on execution sequences characterizing their “executability” 
in any buffer environment. Two such equivalences are proposed, together 
with dedicated asynchronous composition operators able to directly pro- 
duce reduced Lts. 



1 Introduction 

This work takes place in the context of formal verification of distributed pro- 
grams, those purpose is to evaluate a set of expected requirements on a formal 
program description. To automate this activity, one of the promising technique 
is the well-known model- checking approach, which consists of performing the 
verification on an explicit model of the system behaviour (e.g., a labelled tran- 
sition system, or Lts). However, the main drawback of model-checking is the 
model explosion occurring when dealing with complex systems. This still limits 
its large scale utilisation in the industry. 

Several interesting solutions have already been investigated to overcome this 
problem, for instance by avoiding an explicit storage of the whole model ( “on-the- 
fly” techniques), or by processing it using efficient representations (“symbolic” 
techniques) , or by generating a model simpler than the initial one ( “abstraction” 
techniques). A particular instance of this latter solution consists of performing 
the verification not on the Lts S obtained from the original program description, 
but rather on its S/ R quotient where R is an equivalence relation preserving the 
properties under verification. The main difficulty is then to get this quotient 
without generating first the initial Lts. 
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When the program under consideration is described by a composition ex- 
pression between communicating Lts, and provided that i? is a congruence 
with respect to the operators of this expression, the quotient S/R can easily 
be generated with a so-called compositional approach: it consists of (repeatedly) 
generating the Lts S' associated with a given sub-expression, and replacing this 
sub-expression in the initial one by the quotient S' / R. This approach has been 
widely studied [GS90,CK93,Val96,KM97], and has already been applied in some 
succesfull case studies. However, most of this works was done in the context 
of synchronous communicating systems (described for instance using process 
algebras like Lotos [IS087] or Csp [Hoa85]). 

In this paper we propose a way to efficiently extend this compositional gen- 
eration strategy to asynchronous systems communicating by message exchange 
through shared buffers. In fact, this communication scheme is very suitable for 
describing distributed systems or communication protocols, and it is the underly- 
ing model of popular specification formalisms such as the international standard 
Sdl [IT92], or the Promela language [Hol91]. 

One of the main difficulties encountered during a compositional generation is 
to correctly handle the effect of the environment (i.e., the rest of the system) in 
order to restrict the generation of a given subset of components (otherwise the 
model obtained for this subset may be larger than the one corresponding to the 
whole system). This problem was addressed in [GS90,CK93,KM97] by express- 
ing the constraints provided from the environment in terms of process interfaces, 
allowing to “cut off” some parts of a component behaviour. Unfortunately, this 
solution is not applicable in case of asynchronous communications, since the ef- 
fects of the external buffers cannot precisely be statically approximated. Thus, 
many useless interleavings are computed when generating a subsystem indepen- 
dently of its buffer environment. 

To avoid these interleavings, the solution we propose relies on the (well- 
known) partial order approach which consists of identifying independent exe- 
cution sequences that can be safely sequentialized (instead of being fully inter- 
leaved). Such techniques have already rather intensively been studied, and their 
efficiency has been established in practice, in particular for asynchronous com- 
municating systems [Val90,GW91,Pel96,KLM+98]. However, to our knowledge, 
their application in this framework is original by its combination of two aspects: 

— First, partial order reductions are usually performed on the whole system, 
considering the explicit behaviour of each of its components. A contrario, 
the approach we describe here can be applied on a partial sub-system, and 
it allows generation of a reduced Lts (with less interleavings) that can be 
re-used during further compositions. 

— Second, the reductions we consider are not only based on a symmetrical in- 
dependence relation of actions (leading to an equivalence relation between 
independent execution sequences), but also on an asymmetrical notion of 
precedence relation of actions, leading to a preorder between execution se- 
quences. According to this preorder, smallest sequences are always “more 
executabld^ than larger ones in any buffer environment. 
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This notion of non commutative independence relation between actions was 
first introduced by [Lip75] to study the correctness of concurrents processes 
synchronized by means of semaphores. It was also used in [AJKP98] within a 
symbolic verification framework. 

The paper is organized as follows: 

First, we give in section 2 the program syntax we consider (a set of asynchronous 
communicating processes), and we briefly explain how the Lts denoting a pro- 
gram semantics can be compositionally generated in this framework. Then, we 
introduce in section 3 a (syntactic) notion of preorder between execution se- 
quences, and we show how it characterizes the executability of an execution se- 
quence in any buffer environment. Using this preorder, we consider in section 4 
a first equivalence relation , deadlock preserving, and which is a congruence 
w.r.t asynchronous composition. We then propose a new asynchronous compo- 
sition operator, allowing to directly compute a reduced Lts w.r.t and thus 
avoiding many useless interleavings. Finally, in section 5 we extend these results 
to a stronger equivalence relation , able to preserve the language w.r.t a set 
of observable actions. 



2 Asynchronous Communicating Systems 

In this section we give the abstract syntax and semantics used to represent 
asynchronous communicating systems by means of a parallel composition of 
labelled transition systems. Then we indicate how the global state space of such 
systems can be obtained in a compositional way. 



2.1 Program Syntax and Semantics 

A Labelled Transition System (Lts, for short) is a tuple S = {Q, A, T, qo) where 
Q is a finite set of (reachable) states, A a finite set of actions (or labels), 
TCQxAxQa transition relation, and qo G Q the initial state of S. As usual, 
we shall note p — >t Q instead of (p, a, q) € T. 

Let A4 be a set of message names, and Buf a set of unbounded buffers over 
A4. A buffer B G Buf is an abstract type with the following signature, and those 
concrete implementation depends on the exact nature of the buffer (e.g., bags, 
stacks, fifo queues, ... ): 

— T is an empty buffer; 

— first: M X B ^ bool. 

first(m, i?) is true iff message m can be consumed in buffer B. 

— remove: A4 x B ^ B. 

When first(m,i?) holds remove(TO, S) returns the new buffer obtained 
from B by eliminating message m, otherwise B is returned unchanged. 

— append: M. x B ^ B. 

append(m,i?) adds the message m to buffer B. 
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Finally, a program is a couple V = {Sn, Bp) where = {S'!, S2, ■ ■ ■ 5 'n} is a 
finite set of elementary proeesses represented by Lts Si = {Qi, Ai,Ti, qoi), and 
Bp = {Bi, B2, ■ ■ ■ Bp} is a finite set of buffers over Ai. Moreover, for each Sj in 
Sn, action sets Aj C A = M'*' U A~ U {r} where: 

A~^ = I i e [l,p] A m G A 4 } ; A~ = {— (i,m) | i G [l,p] A m G A 4 } 

Informally, for an Lts Sj, action +a = +(i, m) denotes the output of message m 
to the buffer Bi, action —a = denotes the input of message m from 

buffer Bi and r denotes any internal (non communication) action. 

Definition 1 (Program semantics). The semantics of a program V = {Sn, Bp) 
is defined as the Lts sem(P) = (Q,A,T,qo) where: 

- Q c Qi X Q2 X ■ ■ ■ X Qn X Bi X B2 X ■ ■ ■ X Bp 

- qo = (901,902, L) 

- Q and T are the smallest sets obtained when applying the following rules: 

90 G Q 

P = (Pi, ■ ■ ■ ,Pj, Bp) G Q, Pj qj, flrst(m, Bj) 

q = (pi , . . . ,qj,. . .pn, Bi,. , remove(m, Bi), . . . Bp) £ Q, p q 

P = (Pi, ■ ■ ■ ,Pj, ■ ■ -Pn, Bi,...,Bj,... Bp) G Q, Pj qj 

q= {pi, . . . , qj, . . .pn, Bi, . . . ,a.ppend{m, Bi), . . . Bp) G Q, p^^'^r q 

p={pi,...,Pj,...pn,Bi,...,Bj,...Bp)€Q, Pj TAt. qj 

q = (pi,. . .,qj,...p„,Bi,.. .,Bi,...Bp)£Q,p -At q 

2.2 Compositional State Space Generation 

The generation of sem(P) using definition 1 , needs to consider simultaneously 
the whole sets of buffers and elementary processes. However, this resulting 
Lts can also be built in a more compositional way by taking into account each 
program component (i.e., buffer or elementary process) incrementally. To this 
purpose we first introduce two auxiliary operators, the asynchronous product 
between Lts and the execution of an Lts within a given buffer environment. 

The asynchronous product ( || ) between two Lts Si = {Qi, Ai,Ti,qoi) is de- 
fined in the usual manner: 1152 is the Lts S={Q,A,T,qf) where 

Q = QixQ 2,T = {{{pi,p2),a, (91,92)) I (pi -^Ti 9 i A p2 = 92) V {p2 
92 A Pi = 9 i)}, H = Ai U A2, 9 o = (901, 902)- 

Definition 2 (Execution of an Lts within a buffer environment). For an 

Lts S={Q,A,T,qo) and a buffer environment Bp, we note S[Bp] the 
Lts {Qs, A,Ts, Psq) obtained by executing S within Bp, and defined as follows: 



[RO] 

[Rl] 

[R 2 ] 

[R 3 ] 
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— Qs ^ Q X Bi X B2 X ■ ■ ■ X Bp 

Qsq (^0; -L7 • ■ • 5 -L) 

— Qs and Tg are the smallest sets obtained when applying the following rules: 

Qsq ^ Qs 

Ps = Bp) e Qs, p q, Rrst{m,Bi) 

Qs = (g, Bi,. . . , remove(m, Bi), . . . Bp) G Qs, Ps Qs 

Ps = {p,Bi,...,Bj,...Bp) G Qs, q 

qs = {q, Bi, . . . , append(m, Bi), . . . Bp) G Qs, Ps q^ 

Ps = {p,Bi,...,Bj,...Bp) G Qs, P^T q 
Qs — {q, Bl , . . • , Bi , . . . Bp ) G Qs, Ps ^Ts Qs 

It is easy to show that the global Lts sem(T^) can be obtained by considering 
first the asynchronous product of its elementary processes, then executing it w.r.t 
its buffer environment: 

Proposition 1 . For a program V = (Sn,Bp), sem(P) = (S'i ||5'2 || ■ • ■ || 5 '„)[/Bp]. 

Furthermore, this approach can be made even more flexible by partially dis- 
tributing buffers Bp w.r.t a subset of elementary processes. More formally: 

Proposition 2 . Let Si and S2 be two Lts and Bp a buffer environment. 

Consider a split of Bp into three sets Bpi, Bp2 and Bps such that: buffers of 
Bpi are not accessed by S2, buffers of Bp2 are not accessed by Si, and buffers 
of Bps are accessed by both Si and S2- (such a split always exists since Bpi and 
Bp2 can be empty). 

Then, the following holds: {Si || S2)[Bp] = (S'i[,Spi] || S2[Bp2])[Bps] 

Finally, depending on the program properties under consideration, intermedi- 
ate Lts reductions can now be introduced between successive generation steps. 
Furthermore, since internal communications within a sub-system can be ab- 
stracted away before its composition with the other program components, power- 
ful reduction operations are possible when only the external program behaviour 
is relevant. In particular most of the usual bisimulation based weak equiva- 
lence relations (such as observational equivalence [Mil 89 ], branching bisimula- 
tion [vGW 89 ] or safety equivalence [BFG"*’ 91 ]) happen to be congruences w.r.t. 
operators || and [...] and can be used in this framework. 

However, due to asynchronous nature of communications, this (straightfor- 
ward) compositional approach may still suffer from state explosion problems. 
In fact, when generating a subsystem, each append or remove operations 
concerning external buffers is considered as fully asynchronous. This leads to 
many possible interleavings, and, therefore, the size of the resulting intermedi- 
ate Lts may become very large. 

We propose in this paper a solution to decrease the number of these useless 
interleavings by taking advantage of some (well-known) considerations about the 
concurrent execution of independent actions. 



[RO] 
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3 Equivalence and Preorder on Execution Sequences 

First, we give some notations related to the execution sequences of an Lts. 
Then we introduce some equivalence and preorder relations between execution 
sequences. 

Definition 3 (Execution sequences of an Lts). 

Let S = {Q, A, T, qo) be an Lts, and p a given set of Q: 

— Act(p) is the set of actions the state p can perform, and Pre(p) the set of 
actions that may reach it: 

Act(p) = {a & A\^q .p -^T q] ; Pre(p) = {a & A\^q .q -^t p} 
Act~ (p) = Act(p) C\ A~ ; Act^ (p) = Act(p) C\ 

— An (execution^ sequence cr from p is an element a = ai.a2. • • • a„ of A* such 

that: a = p Pi Pn We shall also use the notation 

P ~^T Pn+i, or simply p -^t- 



3.1 Equivalence between Execution Sequences 

The equivalence relation between execution sequences we consider is based on an 
independency relation / on actions. Roughly speaking, two actions oi and 02 will 
be considered as independent ((01,02) G I) if, whenever they are both enabled 
in a given state p, their execution order has no influence on the subsequent 
execution sequences p will be able to perform. 



Definition 4 (Independance of actions). 

A relation I C Ay. A is an independency relation for an Lts S = {Q, A, T, qo) if, 
for all p G Q, and for all (oi, 02) G I then: 



oi, 02 C Act(p) 



Vgi,g 2 GQ .p -At q^ 



A 

A P >T <72 

(02 G Act(qi) A Oi G Act(q2)) 



. Vg G 



^ ai.a2 

Q .p — q 






d2 -0.1 

p — >T q 



We give below some examples of independency relations defined on communi- 
cation actions performed by distinct processes, depending on the kind of buffers 
that are considered. 



Example 1 . When buffers are defined as hags, the order of two append opera- 
tions does not matter. Therefore, two append (resp. remove) operations are 
always independent each others. Moreover, an append and a remove operation 
will be independent if they occur in two different bags. Therefore, Ibag is defined 
as follows: Ibag = A^ x A^UA~ x A~ U {(±(zi, toi), t(*2, TO2)) I ii yf h} When 
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buffers are defined as fifo queues, the order of two append or remove opera- 
tions does not matter only if they occur in different queues. The corresponding 
independency relation is then: 

= {(±(tl,TOl),±(f2,TO2)) I Zl yf Z2} u {(±(zi,TOi),=F(z2,ZrZ2)) | *1 ^ *2} 

Note that internal transitions (r) performed by distinct processes are always 
independent. □. 

Independency relations allow to define equivalence relations on execution 
sequences: two sequences u and v will be considered as equivalent iff u can 
be obtained from v by repeatedly permuting two of its adjacent independent 
actions. 

Definition 5 (Equivalence between execution sequences). 

Let I he an independency relation. For two sequences u,v & A* , write u ^ ]v if 
there exist sequences W\,W2 and actions a,b such that (a,b) € I, u = w\abw2 
and V = w\baw2. Let ^ j be the reflexive and transitive closure of the relation 
~ }. We say that u is L-equivalent with v if u ^ jv. 

Intuitively, if two equivalent sequences cti and <T2 are enabled on a state p, 
then, any buffer environment allowing the execution of a\ also allows the execu- 
tion of (72 (and conversely). Furthermore, buffer contents are updated similarly 
during execution of ai or a2- More formally: 

Proposition 3 . Let S = {Q, A,T,qo) be an Lts, / an independence relation, p 
a state of Q, and ai and (T2 two execution sequences of S such that 3 qi,q2 & Q, 
p ~^T qi, P ~^T q2 and ai ~ /(T2. 

For a given buffer environment Bp, let S' = S[Bp] where S' = {Q' , A, T' , q'^) . 
Then, for any state {p, 6i, 62, . . . , bp) of Q' , the following holds: 

(p, 61, 62, ... , fop) ^T' (<Jl, fo'l, fo^ . . . , fop) yy (p, fol, fo2, . . . , fop) ^T' (<J2, fo'l, h'2,..., fop) 
3.2 Preorder between Execution Sequences 

As stated above, the equivalence relation between execution sequences exactly 
preserves the executability within any buffer environment. We introduce here a 
weaker relation, able to characterize the fact that a given sequence a\ is more 
executable than another sequence (J2 (that is, whenever G2 is executable, then ai 
is). This preorder relation between execution sequence relies itself on a precedency 
relation P between actions: 

Definition 6 (Precedence of actions). 

A relation P Q Ay. A is a precedency relation for an Lts S = {Q, A, T, qo) if, 
for all p G Q, and for all (oi, 02) G P then: 

(\/q2 GQ .p -^T 92 ^ ai G Act(q2) 

01,02 C Act (pj ^ 1 ^ 

I w ^ 0.2. ai ^ 01.02 

yvqGQ.p — >rq=> p — >rq 
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Example 2 . When communications buffers are defined as unbounded bags, an 
append action performed by a process cannot prevent any append or 
remove action performed by another process. The precedency relation on com- 
munication actions between distinct processes is then: Pbag = hag UA+ X A~ 

□ . 

This preorder on A is then extended to a sequence ai is smaller than a 
sequence a2 iff ci can be obtained from a2 by repeatedly permuting any pair of 
its adjacent action belonging to the precedency relation. 

Definition 7 (Preorder between execution sequences). 

For two sequences u,v € A* , write u<\,v if there exist sequences wi,u>2 and 
actions a, 6 such that (a, 6) G P, u = w\abw2 and v = w\baw2- Let ^ p be the 
reflexive and transitive closure o/ ;< p . We say that u is smaller than v (or more 
executable) if u< pV. 

Proposition 3 can now be rephrased as follows: 

Proposition 4. Let S = (Q, A,T,qo) be an Lts, P a precedence relation, p a 
state of Q, and a\ and 02 two execution sequences of S such that 3 qi,q2 & Q, 
p — Ap qi and p — Ap q2 and a\ < p(T2- For a given buffer environment Bp, let 
S' = S[Bp] where S' = {Q', A, T' , q'f). Then, for any state {p, 61, 62, ... , bp) of Q' , 
the following holds: 

{p, 61, 62, ... , bp) Ahp, (gi, b'i,b'2, ...,b'p)^ (p, 61, 62, ... , bp) Ahj., b'l, b'2,..., b'p) 

In the following sections we show how this preorder on execution sequences 
allows to define equivalence relations between Lts that are able to preserve var- 
ious kinds of reachability properties. Moreover, since this preorder characterizes 
the executability of execution sequences, it turns out that these equivalence re- 
lations are congruence w.r.t. the [..] operator and therefore can be used during 
a compositional state space generation. 

Note 1 . We will consider in the sequel that buffers are unbounded bags. Thus, 
we shall note < instead of < p^^ . The extension of this work to fifo queues 
will be briefly discussed in the conclusion. 



4 Deadlock Preservation 

We consider here a first property based on a simple reachability analysis, the 
deadlock freedom of a given program V. More precisely, this property can be 
verified by compositionally generating a reduced Lts S', equivalent to sem(P) 
w.r.t. its deadlock states. To this purpose, we introduce an equivalence relation 
preserving the reachability of any (“equivalent”) potential deadlock states. 
Then, we show that is a congruence w.r.t. operators || and [...]. Finally, 
we propose a new asynchronous composition operator for the direct generation 
of a reduced Lts w.r.t to . 
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4.1 A Deadlock Preserving Equivalence between Lts 

In our framework the only “blocking” actions performed by a program compo- 
nent are the remove operations. Consequently, potential deadlock states are the 
state not able to perform any append (or internal) operation. This set of states 
can be even reduced by considering that a subsequence of adjacent potential 
deadlock states of a same execution sequence can be collapsed into a single one 
(the first state of this subsequence) . Furthermore, two potential deadlock states 
will be considered as equivalent iff a same buffer environment is able to “unlock” 
them (i.e., they can perform the same sets of consecutive remove operations). 

More formally, these potential deadlock states are defined as the stable states 
of an Lts: 

Definition 8 (Stable state). 

Let S = {Q, A,T,qo) be an Lts. For each state q ofQ: 

stable (q ) = {q = qo) V {Act(q)CA~ A Pre(q) D 9) V {Act(q) = %) 

We note stable(5) the set of stable states of S. The equivalence between stable 
states qi and <72 is then the following: 

{ VcTi G A~ . qi -^T => 3cT 2 . (?2 -^T A (72 ~ CTl 
A 

Vct 2 G A~ . q 2 -^T => 3cti . qi A CTi ~ <T 2 

The purpose of equivalence is to preserve reachability of ~ 5 -equivalent 
stable states in any buffer environment. Thus, a sufficient definition would be to 
consider two Lts Si and S 2 as equivalent if, for any stable state of Si reachable 
by an execution sequence cti, it corresponds an equivalent stable state of S 2 , 
reachable by an execution sequence ct 2 , such that tT 2 ^ a\ (and reciprocally 
for any stable state of ^ 2 ). However, we will use here a stronger definition, 
which better corresponds to the behaviour of the composition operator we will 
introduce later (see section 4.2). 

Definition 9 (Equivalence between Lts). 

Let Si = (Qi, Ai, Ti, gOi)j=i 2 Lts. ^ Qi x Q2 is the largest symmet- 

rical relation verifying: 

Pi P 2 GA Wqi G stable(Si) . p\ -^Ti 9 i G stable(S 2 ) ■ 

P2 ~^T2 92 A qi 92 A 0-2 < (Ti A qi 92 

We extend to Lts saying that S\ S 2 iff 9oi 902 • 

Relation preserves deadlocks in any buffer environment: 

Proposition 5. Let Si = (Qi, A^, T,, qOi)i=i 2 two Lts and Bp a buffer envi- 
ronment. For a given Lts S let sink(’S' ) denote the set of state of S without any 
successors by its transition relation. Then: 

Si -5 S 2 => (sink(^i[6p]) = 0 4A sink(52[6p]) = 0) 
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To each execution sequence of P\ leading to a stable state there exists a smaller 
execution sequence of P2, leading to an equivalent stable state (and reciprocally). 
In particular, sequence —x. — x.{+y. + z)* of Pi which not lead to any stable 
state is not preserved by (since it will never lead to a deadlock even after 
further compositions). □. 

Finally, proposition 6 states that relation is a congruence w.r.t opera- 
tors II (asynchronous composition) and [...] (execution within a given buffer 
environment). The proof of this proposition will rely on the following lemma: 

Lemma 1. For two execution sequences and <T2 of A* , we note a\ \ \ ct 2 the 
set of sequences obtained by “asynchronous composition” of a\ and 02- (J\ || ct2 
contains any sequence of A* resulting of an interleaving of a\ and 02- Then, the 
following holds: 

ya G A* . CTi < a2 => yu'2 G {(J2 1 1 cr) . 3 cr( S {a\ \ \ a) such that a[ < a'2 

Proposition 6 (Congruence of ). Let Si, S2 and S be three Lts, and Bp 
a buffer environment. If Si S2 then the following holds: 

Si[Bp] S 2 [Bp] 

Si II S S2 II S 

4.2 A Deadlock Preserving Composition Operator 

The deadlock preserving composition operator S2 is based on the standard 

operator 1 1 of asynchronous composition between processes. Intuitively, the 
resulting Lts could be defined by “cutting off” any non minimal sequences of 
Si II S'2 leading to a stable state (according to the pre-order < , definition 7). 

In practice, this Lts will be obtained by considering as atomic some partic- 
ular subsequences of Si and S2, thus avoiding their full interleaving. Moreover, 
this generation can be performed “on-the-fly” without generating Si 1 1 S'2 . More 
precisely, atomic subsequences that we consider are delimited not only by stable 
states, but also using a particular set of states. These distinguished states are 
called “interleaving” in the sequel and are defined as follows: 

Definition 10 (Interleaving states). 

Let P = (Q , A,T, qo) an Lts. We note int(P) the set of interleaving states of P: 
int(P) = stable(P)U {q G Q \ Act~ (p) A Act^ (p) Pre(p)T A~^ 0} 



( 1 ) 

( 2 ) 
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Formally, atomic subsequences are defined as follows: 

, / \ — -“1 / II +*** 

atom[a) = a = pi — > Pi — > Pi — > qi 



where pi is an interleaving state, qi a stable state, and each p" such that 
Act“(p") yf 0 is an interleaving state. 

The deadlock preserving composition operator between processes can now be 
defined as follows: 



Definition 11 (Deadlock preserving composition operator between 
Lts). 

Let P = Pi®s P 2 with P = (Q,A,T,qo) and P^ = (Qi, Aj, Tj, g0i)i=i,2 



— qo = (901,902); 

— Ac Ai U A 2 ; 

— Q is the smallest set reachable from qo using T. 

— The set of transitions T is computed using the four following rules. For each 
of them we note TL the statement: 

H — Pi — ^Ti 91 A P2 ~^T2 92 A Pi G int(Pi) A P2 G int(P2) 

A atom(ai) A atom{a2) A stable(qi) A stable(q2) 



TL, ai A , (72 A 

(pi,P2) ACy (gi,p2) -^T (91,92), (pi,P2) -^T (pi,92) (9l,92) 



[Rl] 



TL, (71 & A , (72 A 
(P1,P2) -^T (Pl,92) (91,92) 



[R2] 



TL, (71 A , (72 & A 

(pi,P2) ACy [qi,p2) AAt (91,92) 



IRS] 



TL, (71 & A , (72 & A 



(pi,P2) S-At (91, P2) -^T (91,92) or (pi,P2) -^T (pi,92) (9l,92) 



[R41 



Example 4- Let P\ and P 2 be the two Lts represented below. Lts P is the 
product Pi 0s P 2 ■ Dotted arrows indicate non minimal subsequences of Pi 1 1 P 2 
that have been “cut off” . 
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• stable state 

• interleaving state 



P 




Note 2. 

For applying this method, all actions of a\ must be independent with actions of 
(72, which is the case when buffers are bags. 

It remains to prove that this new operator of composition between processes 
preserves w.r.t. the standard asynchronous composition. This is expressed 
in the following proposition: 

Proposition 7. Let Pi and P 2 he two Lts. Then we have Pi || P 2 Pi P 2 - 



5 Observable Language Preservation 

We consider now another kind of reachability property, the (finite) observable 
language generated by a given program V. Here again, our objective is to compo- 
sitionally generate a reduced Lts S' , able to produce the same set of observable 
execution sequences as sem(P). Therefore, we introduce a relation pre- 
serving the language equivalence over a distinguished set O C A of observable 
actions. Then, we show that «o is a congruence w.r.t. operators || and [...], 
and we propose another asynchronous composition operator preserving «o • 



5.1 A Language Preserving Equivalence 

For a given Lts S, we denote by Lq{S) the set of (finite) execution sequences S 
can perform up to a set of observable actions O. Thus, observable states of S are 
the states able to perform any observable actions, and two (observable) states 
will be considered as equivalent iff they can perform the same observable actions. 
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Definition 12 (Observable language, observable states). 

Let S = {Q, A,T^ qo) be an Lts. The observable language over O of S is the 
following set: 

Lo{S) = {(To &0* \Uo = 01.02- ■■■ -On A 

3cr = xl.0i.xl.02. ■ ■ ■ .X*_j^.On-X* . Qo ~^T A I* ^ £>} 

For each state q ofQ: obs(q) = Act(q)C\ O We note obs(S') the set of stable 
states of S and ~o the equivalence relation between two states qi and q 2 defined 
as follows: qi '^o <72= {Act(qi) D O = Act(q 2 ) C] O) 

Clearly, to preserve the observable language of an Lts it is sufficient to pre- 
serve the reachability of each of its observable states (in any buffer environment) 
by execution sequences identical w.r.t. observable actions. Consequently, by re- 
placing “stable” by “observable” (and by ~o) in definition 9, one could easily 
obtain a suitable equivalence relation. 

Unfortunately this straightforward definition of «o is not satisfying, at least 
for two reasons: 

1. Since it completely ignores the effect of execution sequences not containing 
any observable state, the resulting equivalence is not a congruence w.r.t. 
the II operator Therefore, such execution sequences also have to be 
explicitly taken into account, this can be done in practice by preserving 
not only observable states but also the “interleaving” states introduced in 
section 4.2. 

2. A “composed” state {pi,p 2 , ■ ■ -Pn) becomes observable as soon as one of its 
component pi is able to perform an observable action. Thus, asynchronous 
composition produces many “stuttering equivalent” observable states, not 
identified by this definition (since they are reachable by execution sequences 
not comparable w.r.t. <). Relation < should be weakened into a new rela- 
tion < ^ in order to not distinguish these “stuttering equivalent” observable 
states. 

Relation < relies on the following observation: since an append operation 
performed by a given component can never be prevented by its environment (and 
resp. a remove operation may always be prevented), execution sequence +a.u) 
can be considered as “more executable” than oj (resp. sequence uj.a— is “less 
executable” than uj). This suggests to extend the precedency relation P to the 
relation such that: = P U {A'^ x |e}} U {{e} x A~ } 

Relation < is then the extension of P"^ to execution sequences (applying 
definition 7, where < ^ ^ p# ) - It is easy to see that proposition 4 still holds 

for < that is, according to this new preorder, smallest execution sequences 
are always more executable than largest ones in any buffer environment. 

The definition of the language preserving equivalence «o is now the follow- 
ing: 

^ this problem did not occur with because execution sequences without stable 
state cannot lead to a deadlock even after composition with other components. 
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Definition 13 (Equivalence between Lts). 

Let Si = (Qi, Ti, 2 Lts. «o ^ Qi x Q 2 is the largest symmet- 

rical relation verifying: 

Pi ~o P 2 Vgi e {obs(Si)U int(SiJ) . pi ~^Ti 9i => 3^2 G {obs(S 2 )U int(S 2 j) ■ 
P2 ~^T2 92 A qi ~0 92 A (72 < *<Ji A 9 i 92 A 
Vwi e A* . qi -^Ti = 1 ^ 3 w 2 G yl* . 92 -^Ta A W 2 < 

FFe say i/iai Si «o *52 iff 901 «o 90a • 

Relation Wq preserves observable language over O 

Proposition 8. Let Si and S 2 be two Lts and Bp a buffer environment. 

Si^oS2 ^ Lo{Si[Bp]) = Lo{S2[Bp]) 

Finally, we show that relation rSq is a congruence w.r.t operators || (asyn- 
chronous composition) and [...] (execution within a given buffer environment). 
Here again, the proof of this proposition will rely on lemma 1, which also applies 
to preorder < . 

Proposition 9. Let Si, S 2 and S = (Q,A,T,qo) be three Lts, and Bp a buffer 
environment. Lf Si ~o S 2 then the following holds: 

Si II 5 52 II 5 (3) 

Si[Bp] S2[Bp] (4) 



5.2 A Language Preserving Composition Operator 

We briefly explain here how the composition operator 05 defined in section 4.2 
can be modified into a 0o operator preserving Wq -equivalence. The underlying 
idea is now to consider as atomic parts of execution sequences delimited either by 
“interleaving” states or observable states. However, the set of interleaving states 
considered in definition 10 have to be augmented in order to deal with “terminal” 
subsequences which do no contain any interleaving state (such sequences are 
necessarily ended by a loop of ^'''-actions). A practical way is to add to the 
interleaving set of states any element of this A'^-loop (these states are computed 
during the construction of Si iS>o S 2 ). 

Such sequences are then of the form: atom{a) = a = pi — ^ Pi V q.^ 

Moreover, as in section 4.2, a complete interleaving between a pair of atomic 
sequences cti and (72 is required only when both ai and (72 contain a combination 
of append and remove actions (otherwise it is enough to consider only the 
smallest element of the ordered set {ai.a 2 ,(J 2 -cri})- 

Formally, operator 0o is obtained by modifying definition of 0^ (defini- 
tion 11) as follows: 
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Definition 14 (Language preserving composition operator). 

Let P = Pi iS>o P2 with P = {Q,A,T,qo) and Pi = (Qi, g0i),=i,2 

— qo = (901,902); 

— ^4 C Ai U A2; 

— Q is the smallest set reachable from qq using T. 

— The set of transitions T is computed using the following four rules. For each 
of them, we note TL the following statement: 

H — pi -^Ti 91 A P2 ~^T2 92 a Pi e int(Pi ) U obs(Pi ) A P2 € int(P2 ) U obs(P2 ) 
A atom{ai) A atom{a2) A (int(qi) V obs(qij) A {int(q2) V obs(q2)) 



TL, a\ A , 02 f: A a\ , 02 A~^ 



(pi,P2) -^T (gi,P2) -^T (91,92), (Pl,P2) -^T (pi,92) ~^T (gi,92) 

Tt, 01 G A~ , 02 A~ 

(P 1 ,P 2 ) (P 1 , 92 ) (91,92) 

Ti, 01 A~ , 02 G A~ 

(pi,P2) (91, P2) -^T (91,92) 

7 i, {01 G A~ A 02 £ A~ ) V (<Ti G A+ A 02 € A~^ ) 

(pi,P2) ~^T (91, P2) ~^T (91,92) or (pi,P2) -^T (pi,92) -^T (91,92) 



/i?ty 

[R 2 ] 

[R 3 ] 

mi 



Using similar arguments than in section 4.2 it is possible to show that this 
operator preserves Wq w.r.t. the standard asynchronous composition: 

Proposition 10 . Let Pi and P2 be two Lts. Then we have Pi \ \ P2 ~o Pi P2 

6 Conclusion and Future Works 

We have proposed a state space generation method for asynchronous commu- 
nicating processes which combines the benefits of both compositionality (gen- 
eration and reduction steps are performed incrementally), and partial- order re- 
duction techniques (only some representative elements of the set of execution 
sequences are considered) . 

More precisely, our approach was based on a syntactic notion of precedence 
of communication actions, leading to a preorder between execution sequences 
able to characterize their “executability” in any external buffer environments 
(smallest sequences are the most executable). Using this preorder, we proposed 
two equivalence relations between Lts, based on a similar notion of reachability 
of a distinguished set of states through most executable execution sequences. 
These two equivalence relations respectively preserve deadlock states and the 
system language up to a given set of observable actions. Moreover, they are 
congruences w.r.t. asynchronous composition. Finally, we have also defined two 
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asynchronous composition operators, able to directly generate reduced Lts w.r.t. 
each of these relations. These operators differ on the standard one by considering 
as atomic particular subsequences of each process, thus saving many useless 
interleavings. 

A first prototype implementation has been experimented within the If en- 
vironment developed at Verimag for the verification of asynchronous commu- 
nicating systems [BFG+99]. The results obtained on a “benchmark” example 
(a leader election algorithm) largely confirm the interest of this compositional 
approach (about 5 000 generated states instead of 20 000 using a simultaneous 
composition, when verifying observable language preservation). It now remains 
to extend this experience to others case-studies, in particular to see how our 
approach compares with more “classical” partial-order reduction techniques (for 
instance the one implemented in Spin [Ho191]). 

One of the practical motivation behind this work is to apply compositional 
generation techniques to the verification of industrial size Sdl specifications. To 
this purpose, the results proposed here will have to be (fully) extended to the 
case of asynchronous communications via fifo queues (instead of their abstrac- 
tion in terms of bags). In this case, the “purely syntactic” definition of precedence 
relation between actions we considered here may be to strict, and it would be 
interesting to see how it can be enlarged using more sophisticated static analysis 
techniques (for instance depending on the communication topology between pro- 
cesses). To this purpose, a suitable framework could be provided by the notion 
of conditional independence proposed in [KP92] . 
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Abstract. This paper describes an on-the-fly technique for computing 
the CFFD-preorder relation on two labelled transition systems (LTSs). 
CFFD is a process-algebraic semantic model for comparing processes. It 
is a modification of the CSP model. LTSs are used as a representation of 
processes. The presented technique is based on transforming the specifi- 
cation process into a special tester process. The tester is then composed in 
parallel with the processes of the implementation. Violations against the 
specification are detected as illegal states, deadlocks and livelocks during 
the computation of the composition. Tester processes are an extension 
of Brinksma’s canonical testers. Using a tester process can be a substan- 
tially faster method of computing CFFD-preorder than the previously 
used method of comparing acceptance graphs. 



1 Introduction and Motivation 

This work is based on process-algebraic theories such as Calculus of Communi- 
cating Systems (CCS) [11], Communicating Sequential Processes (CSP) [5] [14], 
and Chaos-Free Failures-Divergences (CFFD) [18,19]. These theories define ways 
to compare processes. Each of them defines its own notion of equivalence, that 
is, defines when the behaviours of two processes are considered equivalent. 

The semantic model used in this paper is CFFD, which is a further develop- 
ment of CSP. Unlike CSP, the CFFD theory can distinguish between different be- 
haviours after a possible livelock. CSP considers all livelock situations as “chaos” 
and therefore equivalent, no matter what can happen after the potential livelock. 
CFFD avoids this problem, hence the name “Chaos-Free Failures-Divergences” . 

In this paper it is assumed that the processes are formally modelled as la- 
belled transition systems (LTS), or parallel compositions thereof. LTSs resemble 
nondeterministic automata. The key difference is that an LTS has no accepting 
states, and, in addition to the normal alphabet, there is a special invisible action 
r. T resembles the e of automata theory, but is usually given more significance. 

Many process-algebraic theories contain a preorder relation that can be con- 
sidered as an implementation relation: a system Sys is a legal implementation 
of a specification Spec, if and only if Sys < Spec. A detailed analysis of many of 
them is in [9]. The CFFD-preorder “<cpfd” is particularly interesting, because 
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— it has nice compositional properties, so it is suitable for compositional veri- 
fication; 

— it handles livelocks in a satisfactory way; and 

— it has an interesting connection to ordinary state-based linear-time temporal 
logic (LTL) [10]. 

Namely, if Sys <cpfd Spec holds and Spec satisfies an LTL formula, then also 
Sys satisfies it, provided that the values of the atomic propositions of the formula 
are fully determined by the non-r actions executed so far, and the formula does 
not contain the “next state” operator [7]. (Notice that Sys may satisfy also 
formulas that Spec does not satisfy.) This is an important property, because 
LTL is one of the most important formalisms used for specifying systems, “next 
state” is usually considered irrelevant in concurrency contexts, and the r-actions 
can be chosen according to the atomic propositions of the formula. Furthermore, 
all major process-algebraic preorders lack this property because of the way they 
handle livelocks. There are less well known preorders that have the property and 
some that also preserve deadlocks, but CFFD-preorder can be shown to be the 
coarsest compositional one among them [7]. 

CFFD-preorder guarantees that Sys has only “legal” execution traces (those 
specified by Spec), Sys has only legal refusal sets (a generalization of deadlocks), 
and Sys can livelock only when specified by Spec. It implies testing preorder, or 
failure preorder [1]. 

Checking of Sys <cpfd Spec is PSPACE-complete in the size of Spec. On the 
other hand, it can be done in low-order polynomial time in the size of Sys. We 
will develop an algorithm that is exponential in the size of Spec and fast in the 
size of Sys. It is based on converting Spec into a special tester process, putting 
it in parallel with Sys, and checking for certain conditions when computing the 
parallel composition of Sys and tester (Spec). In addition to being cheap in terms 
of the size of Sys, the algorithm has the advantage that it can detect errors on- 
the-fly, that is, during the construction of an LTS for Sys. This is obtained by 
presenting Sys as a parallel composition of several processes Pi, P 2 , .. . , Pn, and 
computing Pi || T2 • |l II tester (Spec) and simultaneously checking for the 
error detection conditions. As was discussed in detail in [16] Section 4.2, on- 
the-fly verification may save a lot of effort when analysing erroneous systems, 
compared to fully computing the LTSs of Spec and Sys before comparing them. 

Many of the fundamental ideas presented in this paper are not new. They 
can be found from the literature on reduction algorithms in classic automata 
theory, the theory of canonical testers [2], and the CSP model checking in the 
FDR tool [13,14]. However, as far as we know, this is the first time that the 
theory of tester processes is put together and presented in an organized man- 
ner. Furthermore, nontrivial new ideas were needed for adding the handling of 
divergences in an appropriate way, and, as we pointed out above, divergences 
are necessary for checking the absence of illegal livelocks. 

Other algorithms for checking a preorder that resembles CFFD have been 
proposed in [3,13]. The [3] approach is exponential also in the size of Sys. The [13] 
approach is rather similar to ours and has more or less the same complexity. The 
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main difference, in addition to the important fact that our approach handles also 
livelocks, is that some things that the [13] approach postpones to the computa- 
tion of the parallel composition are done already during the tester construction 
in our method. Therefore, our method states less requirements to the parallel 
composition tool. (Please be not confused by the fact that the handling of live- 
locks causes a rather strict requirement in our method — this should not be 
taken into account when comparing to [13], because the latter treats livelocks as 
“chaos”.) 

The algorithm described in Section 4 has been implemented as an addition 
to the “Advanced Reachability Analysis” verification tool set, which has been 
developed by VTT Electronics and the Verification Algorithm Research Group 
at Tampere University of Technology [17]. 

Section 2 recalls the basic definitions. In Section 3 the notion of acceptance 
graphs is introduced. Our new method is described in Section 4. 



2 Background 

2.1 CFFD Semantics 

The CFFD semantics is a semantic model for labelled transition systems (LTS). 
It is a modification of the CSP model [5] [14]. The CFFD model differs from the 
CSP model in the handling of (possible) divergences. The CFFD model records 
the behavior of the system after divergences whereas the CSP model disregards 
any behavior after the first divergence. The CFFD model is described in detail 
in [18] and [19]. Here are some definitions of the concepts used in this paper. 

Definition 1 (Labelled transition system) LTS P is the 4~tuple P = (S', A, 
Z\,s), where S is the set of states, A is the finite set of visible action symbols. 
There is also the invisible action t ^ S . A C S x (A U {t}) x S is the set of 
transitions and s € S is the initial state. 

In addition to the alphabet symbols in A there is the invisible action r. It 
denotes some execution step which is internal to the system and its execution 
cannot be directly observed in the execution behavior of the LTS. 

Definition 2 (Arrow notation) The following are more convenient notations 
for executions of an LTS. 

— s -a—>- s' iff (s, a, s') G A 

— s -aiQ 2 . . . a„— > s' iff 

3so, Si, . . . , Sji . S — Sq a Sq 0\ ^ Si 0.2 ^ ‘ ■ ■ ^ A S — S^i- 

— // (T = 0102 ... o„ then s —aia^ ■ ■ ■ an—> s' can he written s — cr— > s' . 

— s iff 3s' : s — cr— > s' 

— s = 0 i 02 . . . o„=> s' iff s —T*a\T*a 2 T* . . . T*anT*^ s' , where each r* denotes 
any sequence of zero or more r-actions, and none of Oi is r. 

— s =(T=J> iff 3s' : s =(T=> s' 
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Parallel composition is an operator which combines many LTSs into one. We 
use a parallel composition operator that synchronizes all visible actions which 
occur in the alphabets of more than one component LTS. 



Definition 3 (Parallel composition) Let L\ = (S'!, Z\i, si), . . . , = 

{Sn, LJn, ^n, Sn) ■ Their parallel composition Li\\ ■ ■ ■ || L„ = {S,E,A, s), where 



- S= Six S2y.---y.Sn 

- r = A'l u Tz u • • • u 

- (s, a, s') G A, where 

s = (si, ... , s„) e S' A s' = (s(, . . . , s'„) e S, 

(sj, r, s') G Z\j and 



a = T A 3iG{l,...,n}: 



iff either < 



a G A Vi G {1, . . . , n} : 

S — (si, S2, ... 5 Sn) 



[_Vj -{j ^i^ s' = Sj) or 
a G Ei ^ (si, a, s') G Ai and 
a El ^ s', = Si 



The LTSs generated by this definition of composition contain unreachable 
states. In practice, these states can be ignored, since they don’t affect the be- 
havior of the LTS. In other words, only states s which satisfy 3a : s —a^ s are 
important. 



Definition 4 ('Traces) The set of traces of an LTS P = (S, E, A, s) is tr{P) = 
{^a G E* I s =(j=t> } 

Definition 5 (Stable failures) The set of stable failures of an LTS P is the 
set of pairs sfail{P) = \^{a,R) G E* y 2^ | 3s : s =cr=^ s A Vo G i? U {r} : 
^(s -a-^ ) }. The set R is called a refusal set. 

The number of refusal sets for a given a is often very large. All subsets of a 
refusal set are also refusal sets, that is (a,R) G sfail(P) A R' C R ^ (o', i?') G 
sfail{P). Therefore, the stable failures with maximal refusal sets with respect to 
C completely determine the set of stable failures. 

Sometimes it is more convenient to use acceptance sets instead of refusal 
sets. Acceptance sets are the complements of refusal sets. Complements of the 
maximal refusal sets are the minimal acceptance sets. 



Definition 6 (Deadlock traces) The set of deadlock traces of an LTS P is 
the set dltr{P) = { cr G tr{P) | 3s : (s =(t=^ s A Vo G E U {t} : ^(s —a^ )) } 

Thus 

Theorem 1 dltr{P) = { o' | (a, E) G sfail{P) }. 

Definition 7 (Divergence traces) The set of divergence traces of an LTS P 
is the set divtr(P) = { cr | 3s : s =cr=^ s A s — } 
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Here denotes an infinite sequence of invisible events. Similarly, denotes 
all infinite sequences of visible actions. 

Traces can be derived from stable failures and divergence traces [15]: 

Theorem 2 tr{P) = divtr{P) U { ct | (ct, 0) G sfail{P) }. 

Definition 8 (Infinite traces) If P is an LTS, then 
inftr(P) = { (T G 17“ | s =cr=i> } 

Definition 9 (Stability) State s is stable iff there are no invisible transitions 
from it: stable(s) ~^{s — t— *■ ). An LTS P is stable iff its initial state is stable. 

Definition 10 (CFFD-equivalence) LTSs P and Q are CFFD- equivalent, 
written P =cffd Q, iff ^{P) = ^(Q) A stable{P) = stable{Q) A sfail{P) = 
sfail{Q) A divtr{P) = divtr{Q) A inftr{P) = inftr{Q) 

There are five components {S, stable {), s fail {), divtr{) and inftr()) in the 
CFFD-equivalence. In the case of finite state systems the m/tr()-component 
follows from the other components: 

Theorem 3 If P is a finite state LTS, then inftr(P) = { w G | Vcr < w : 
a G tr{P) } . 

The proof can be found in [19]. 

The following formulae are intended to illustrate the relation between CFFD 
and CSP [12,15]. Let p < a denote that p is a prefix of cr. Let P be an LTS. 
Then its CSP-divergences and CSP-failures are 

Definition 11 (CSP-divergences and CSP-failures) CSPdiv{P) = { cr G 
E* I 3p G divtr{P) : p < cr } and CSPfail{P) = sfail{P) U {CSPdiv{P) x 2^). 

2.2 CFFD-Preorder 

The CFFD-preorder is a relation which is used to compare two LTSs. One of the 
LTSs represents the specification (S') and the other represents the implementa- 
tion (/). The relation is written I <cpfd S. 

Definition 12 (CFFD-preorder) If P and Q are LTSs, then P <offd Q iff 

1. E{P) = E(Q) , 

2. stable(P) V —‘Stable{Q) , (or, equivalently, stable (Q) stable{P)) 

3. sfail{P) C sfail(Q) , 

4- divtr(P) C divtr{Q) and 
5. inftr(P) C inftr(Q) 

This relation is both reflexive and transitive, so it is a preorder. The equiv- 
alence induced by this preorder is the CFFD-equivalence. That is, P <cppd 
Q A Q ^CPPD P ^ p P =CPPD Q- 

If the LTSs are both finite, then the fifth property follows from the 3rd 
and 4th. 
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Property 1 tells that the implementation and specification should be inter- 
ested in the same set of actions. Property 2 tells that if the specification is stable, 
then the implementation must be also stable. In general, the specification may 
contain more nondeterminism than the implementation but not the other way 
around. Property 3 states that the implementation is allowed to refuse some set 
R C S of actions after executing a trace a G S* only if the specification can 
execute a and then refuse R. 

The implementation does not have to refuse everything that the specification 
may refuse. When considering the acceptance sets instead of refusal sets, the 
situation is complementary: After executing a the implementation should always 
be able to accept some superset of one of the specification’s acceptance sets. Note 
that this property only speaks of the stable states. 

Property 4 means that the implementation is allowed to diverge (livelock) 
after executing some trace only if also the specification can diverge after that 
trace. The implementation may also choose not to livelock even if the specifica- 
tion allows it to do so, but then the implementation refuses at least 0 after the 
trace, which may violate property 3. 

Property 5 is important only in the case of infinite state systems as Theorem 3 
states. In [19] this issue is presented in more detail. 

Definition 12 (properties 3 and 4) with theorems 1 and 2 implies two addi- 
tional properties: 

Theorem 4 If P <cffd Q then 6. tr{P) C tr{Q) and 7. dltr{P) C dltr{Q) 

2.3 The Complexity of Checking CFFD-Preorder 

The checking of equivalence according to a semantics that is based on failures is 
typically PSPACE-complete [8]. This applies also to CFFD-semantics. Because 
P ^cppD Q P ^cppD Q A Q ^cppD F 5 the problem of checking P Q 

must be PSPACF-hard in the size of at least one of P and Q. The next theorem 
states that it is hard in the size of Q. On the other hand, as will be described in 
Section 4.1, it can be done in low-order polynomial time in the size of P. 

Theorem 5 Checking that P <cffd Q is PSPACE-complete in the size of Q. 

Proof. If P <CPPD Q does not hold, then at least one of properties 1 to 4 of 
Definition 12 does not hold. The first two are trivial to check. If the property 3 or 
4 does not hold, P and Q have a trace cr such that either there is an action a such 
that era G tr{P) but era ^ tr{Q); or there is A C if such that (cr. A) G sfail{P) 
but (cr. A) sfail{Q); or cr € divtr{P) but cr ^ divtr{Q). A nondeterministic 
algorithm can guess the kind of error and then one by one guess the steps of an 
execution of P that yields a as the trace, and leads P to a state with an illegal 
next action a, refusal set A, or divergence. The algorithm simultaneously keeps 
track of all the states that Q may be in after executing the same trace as P has 
so far executed. 

At some point the algorithm guesses that the execution has been completed. 
Then it verifies that P can continue with a or refuse A or diverge from its current 
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state, but Q cannot from any of the states in its current set of states. Thanks 
to the interleaving of the steps of P and Q, neither the (possibly exponentially 
long) execution nor its trace cr needs to be stored. Keeping track of the set of 
states of Q requires two or three bits per each state of Q. So polynomial space 
suffices. Thus P ^cpfd Q can be checked in nondeterministic polynomial space, 
and NPSPACE is know to be the same as PSPACE. 

It remains to be proven that checking P <cppd Q is PSPACE-hard. The 
checking whether a nondeterministic finite automaton N = (S, E, A, s, F) ac- 
cepts all traces (known as “words” in automata theory) in its alphabet is a 
well-known PSPACE-complete problem. (E C S' is the set of acceptance states; 
the other components are like in an LTS; and the automaton accepts a trace 
if and only if it has an execution that produces that trace and ends in an ac- 
ceptance state.) This problem can be reduced to the checking of P <cppd Q in 
polynomial time as follows. 

First, N is converted to the LTS Li = (Si, Ai, Z\i, s), where Si = SU {s^}, 
Ai = A U {a#}, Z\i = Z\ U { (s, a#, s#) | s G E } U { {s#,a, s^) \ a & Si), 
and s^ and are new (i.e., s^ ^ S and ^ A). That is, a new state is 
added such that it can be reached from each original acceptance state by a^, 
and from itself by just any visible action. If N rejects some trace cr, then aa^ ^ 
tr{Li). Otherwise, L\ can execute any a G A* in such a way that it can then 
continue with and any element of A*. Thus N accepts all traces if and only 
if tr{L\) = AJ. 

Next Si, Ai and s are replaced with S2 = { [[s]] | s G Si } and A2 = 
{ ([[s]],a, [[s']]) I (s,a, s') G Z\i } and S2 = [[s]], where [[s]] = { s'gSi | s=e=^s'A 
s' =£=J> s}, yielding L2 = (S2, Ai, A2, S2). In other words, each strongly con- 
nected component is collapsed into an individual state, where only r-transitions 
are taken into account when checking strong connectivity. Very efficient algo- 
rithms are known for this, and tr{Li) is not changed, that is, tr{L2) = tr{Li). 

Finally a new initial state and r-transition are added, a new deadlock state 
is added and made reachable from any old state by one r-transition, and all 
“self-loop” r-transitions are removed. More formally: S3 = S2 U {s/,sd}, A3 = 
A2 U {(s/, r, S2)} U { (s, r, sd) I s G S2 } - { (s, r, s) | s G S3 }, and S3 = s/, 
where s/ ^ S2 and sd ^ S2- This conversion leaves tr{L2) intact, and ensures 
that stable{L^) = false, sfail{L^) = tr{L^) x 2^% and divtr{L^) = 0. 

Consider the LTS L' = ({si, S2}, Ai, A', si), where A' = {(si,r, S2)} U 
{ (si,a, si) I a G Ai }. We have stable(L') = false, sfail(L') = AJ x and 
divtr(L') = 0. Therefore, L' <cppd L3 holds if and only if A* C tr{L^). On the 
other hand, tr{L^) C AJ by definition, and tr{L^) = tr{Li) by construction. 
So E' <CPPD E3 holds if and only if tr{Li) = AJ, which, in turn, was shown 
equivalent to N accepting all traces in its alphabet. □ 
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3 Acceptance Graphs 

In order to check whether the relation P <cppd Q holds, we have to check if the 
properties 1-5 of Definition 12 hold for them. If we assume that Q does not have 
an infinite number of states, then property 5 need not be checked. 

Properties 1 and 2 are simple. Equivalence of alphabets is just a set compar- 
ison. The values of stable(P) and stable(Q) can be obtained by inspecting the 
output transitions of the initial states of P and Q, and from then on the check 
of property 2 consists of simple Boolean arithmetic. 

To check for properties 3 and 4 we rely on the idea of acceptance graphs, 
which are a modification of acceptance trees of [4] . They are deterministic LTSs 
with some additional information. 

Definition 13 (Acceptance Graph) An acceptance graph (AG) is the 7- 
tuple {S, S, S, s, accsets, divok, stable), where 

— S is the set of states. 

— S is the alphabet. 

— 5 is a set of transitions, unlike in LTSs, it is a partial function S x IJ S . 

— s € S is the initial state. 

— accsets(s) is an attribute of each state in S. Its value is a set of sub- 
sets of E such that no set is a subset of another. That is, if accsets(s) = 
{Ai, A 2 , . . . , Ak\ , then Ai Aj whenever i^j. 

— divok(s) is a Boolean attribute of each state in S. 

— stable is a Boolean attribute of the entire AG. 

Because an acceptance graph is deterministic, it can be exponentially bigger 
than a CFFD-equivalent LTS. Acceptance graphs may thus be expensive to use. 

Acceptance graphs and their construction are described in more detail in [18]. 
Now we will only briefly review the structure of an AG. 

An acceptance graph can represent the same information as the CFFD-model 
of finite LTSs, namely the alphabet, stability, stable failures, and divergence 
traces. The main difference is that an AG contains no invisible transitions and 
it is deterministic. 

Since the AG is deterministic, each trace a leads to a unique state s. If 
a S divtr{P) in the LTS representation, then the corresponding state in the AG 
has its divok = true. The stable failures are stored as minimal acceptance sets in 
each state. If there are stable failures (cr, i?i), (<t, i? 2 ), • ■ ■ associated with trace 
a, then we take the maximal ones among the refusal sets i?i , i? 2 , ■ ■ ■ , compute 
their complements in order to save space and store these complements (minimal 
acceptance sets) as an attribute to the AG state s reachable with trace a. The 
initial stability information is stored as a separate attribute of the entire AG. 

4 Checking CFFD-Preorder with Tester Processes 

4.1 Use of the Tester 

A tester process is an augmented LTS which can be used to check GFFD-preorder 
P <cPFD Q without determinising P. Like in the previous checking method, the 
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parts 1 and 2 of Definition 12 are checked separately. The parts 3 and 4 are 
checked by computing the parallel composition of the tester and the original 
LTS P. Any violations of the conditions 3 and 4 for CFFD-preorder can be seen 
as a result of this construction. 

The tester is “almost” deterministic. Given any trace a, either the tester 
cannot execute it at all, or the tester is in a unique state immediately after 
executing a. From this state there may be zero or more r-transitions, but their 
end states are stable. 

In addition to the components of a normal LTS, the tester will have up to 
three checks in each of its states. These may be considered as Boolean values 
attached to the states. Each state can be marked as a rejection state, deadlock 
rejection state or livelock rejection state, or any combination of these. The values 
of these flags on the state s are given by the functions reject(s), DL-reject(s) 
and LL-reject(s). They should be observed when constructing the parallel com- 
position of the tester and the implementation under test. 

If the parallel composition ever reaches a state where the tester is in a re- 
jection state, it is considered an error of the implementation. Similarly, if the 
parallel composition deadlocks when the tester is in a deadlock rejection state, or 
livelocks when the tester is in a livelock rejection state, then these are considered 
illegal behavior of the implementation. 

Violations against rejection and deadlock rejection states are easy to de- 
tect on-the-fly, that is, during the construction of the parallel composition. An 
efficient algorithm for on-the-fly detection of also violations against livelock re- 
jection states was described in [20]. The algorithm is based on constructing the 
parallel composition in a certain order, and monitoring for loops consisting solely 
of T-transitions. Also the “non-progress cycle” detection algorithm of [6] can be 
used for the task, but [16] argues that it is usually less efficient. 



4.2 Construction of the Tester 

We shall present an algorithm that converts the acceptance graph of Q into a 
tester process tester (Q). It needs the notion of the minimal mirror collection [2] 
of a collection of sets. 

Definition 14 (Set mirroring) Let A = {Ai, A 2 , . . . ,A„}, where Ai C S 
when i = 1, . . . ,n be a collection of subsets of S. Define intersect(A) = { B C 
B I Vj G {1, . ■ • ,n} : Aj Cl B yf 0 } . The minimal mirror collection of A is the 
set of the minimal members of inter sect (A): 

Mirror{A) = { M G intersect{A) | —AM' : AI' C M A AI' G intersect(A) }. 

Notice that this definition implies Mirror({ai, 02 , ■ ■ . ,a„}) = {{ai},{a 2 }, 
■ • • ,{o„}}, Mirror{i!l) = {0} and Mirror({0}) = 0. The name suggests that the 
mirror image of a mirror image of a collection should be the original collection. 
This is not true in general, but holds if no set in the original collection is a subset 
of another. 
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Algorithm 1 Tester LTS Construction 

Input: An acceptance graph AG{Q) = {Sq, Sq, Aq, sq, accsetSQ, divokQ, stableg) 
of LTS Q. 

Create a new state Sfaii- Sq U {sfaii} 

reject(sfaii) true ; LL-reject(sfaii) := true ; DL-reject(sfaii) true 
For each state s € Sq such that s ^ Sfaii: 

reject(s) := false ; LL-reject(s) := -^divok{s) 

DL-reject(s) := {accsetSQ{s) 7 ^ {0}) 

For each a € Sq such that -i(s —a^ ): 

Create a new transition s —a^ Sfaii- 

end 

M := Mirror{accsets{s)) 

For each A £ M\ 

Create a new state sa- ;5^:=S^UW} 

Create a new transition s — sa- 

reject(sA) := false ; DL-reject(sA) := DL-reject(s) 

LL-reject(sA) := LL-reject(s) 

For each a € A and s' € Sq such that s —a^ s': 

Create a new transition sa —a^ s' . 

Mark the transition s —a^ s' for removal. 

end 

end 

Remove marked transitions. 

end 

Output: tester{Q) = (S'q, X'q, Z\q, sq, reject, DL-reject, LL-reject) 

end 



Theorem 6 

If ^1 then Mirror {{ Ai, A 2 , . . . , A}) = Mirror{{Ai, A 2 , . . . , A^}). 

2. If no member of A is a subset of another, then Mirror {Mirror {A)) = A. 

The proof is skipped because of lack of space. 

We are now ready to present the tester construction algorithm. It is the 
enclosed Algorithm 1. It works by adding new states and transitions to AG{Q), 
deleting some old transitions, and setting the reject- etc. flags of all states. These 
operations are guided by the accsets- and dzwofc-attributes of AG{Q). 

In theory, the reject flag is not necessary. The only state where it is on, 
namely Sfaii, has no output transitions. Furthermore, the tester has the same 
visible actions as the specification Q and the implementation P. Therefore, if 
P II tester{Q) reaches a state where tester{Q) is in Sfaii, then it can continue only 
with invisible actions. If it can do an infinite number of them, then it livelocks, 
otherwise it eventually deadlocks. Thus the reaching of Sfaii would be detected as 
a violation against LL-reject(sfaii) or DL-reject(sfaii). However, the reject flag is 
extremely easy to implement, and it makes it possible to catch the error sooner. 
Early catching of errors is a virtue of on-the-fly verification. 
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(a) Specification 
LTS Spec 



(b) Acceptance Graph (c) Tester LTS 
AG{Spec) tester{Spec) 



Fig. 1. Stages of the tester construction 



Also the DL-reject-flags are unnecessary in theory, but helpful in practice. 
They could be avoided by adding the transition s — r— > s to every original 
state s of AG{Q) when starting to process s in the algorithm, and treating 
every state as a DL-reject-state. Then the parallel composition cannot dead- 
lock in s because the tester can livelock there; it can deadlock only when the 
tester is in some state sa that the algorithm added to cater for a set A in 
Mirror (accsets(s)). If the specification allows deadlocking, then accsets(s) = {0} 
and Mirror (accsets(s)) = 0, so there will be no sa- However, letting the tester 
livelock would complicate the use of the LL-reject- flags, as one would then have 
to distinguish those livelocks that are not due to the tester. It would also cause 
a small increase in the size of the parallel composition LTS. 

The construction of the tester may be sped up by minimizing AG{Q) [18] 
before tester construction. 



4.3 An Example Tester 

The LTS Spec in Figure 1 contains three explicitly shown states, which represent 
possible states after some trace a. All three are reachable with the same trace 
from the initial state somewhere in the “cloud” . The alphabet of this specification 
is if = {a, 6, c, d, e}. 

In the acceptance graph fragment all three states are combined into one, since 
they are reachable by the same trace and different stable failures are represented 
by different acceptance sets in this state. Notice that the state with divergence is 
unstable and therefore does not generate an acceptance set of its own. However, 
the divergence state causes the divok-Ra-g of the AG state to be set. The mirror 
image of these acceptance sets is Mirror{{{a}, {b, c}}) = {{a, 6}, {a, c}}. 

The tester generated from the acceptance graph shows a new “child” state 
and a r-transition to it for each mirrored acceptance set. The visible transitions 
from the original state have been moved and possibly duplicated to begin from 
the child states. The transition labelled d is not a member of any acceptance set. 
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SO it has been left intact. The trace ae is illegal, so that trace leads the tester 
immediately to the failure state Sfaii- 

4.4 How Does the Tester Work 

Consider the parallel composition of a tester with another LTS. From it one 
should be able to tell if any of the properties of the CFFD-preorder are violated. 
In fact, sfail{P) C sfail{Q) and divtr{P) C divtr{Q) are the only interesting 
properties, since the alphabet and stability are easy to check without testers, 
and infinite traces are relevant only if Q has infinitely many states. 

Traces First of all, the parallel composition can verify tr{P) C tr{Q). Due 
to its construction, AG(Q) has the same set of traces as Q. If P has a finite 
trace CTfaii that Q cannot execute, then it has a (possibly empty) longest prefix 
Cfaii < CTfaii which is a trace of both processes. After executing AG{Q) will 
be in a state where it cannot continue with the next visible action in (Jfaii. An at- 
tempt to execute this action will lead tester{Q) immediately to Sfaii.On the other 
hand, because AG{Q) is deterministic and tester{Q) inherits its structure from 
AG{Q), Sfaii can be reached only by an illegal trace. Therefore, tr{P) ^ tr{Q) if 
and only if the parallel composition will contain a transition to Sfaii. 

Divergence Traces Since AG{Q) is deterministic, each of its traces uniquely 
determines a state, where execution ends up after that trace. The LTS Q can 
diverge after some trace cr iff AG{Q) has its divok-Ra,g set in the state s deter- 
mined by cr. The tester constructed using the above algorithm has all the states 
of AG(Q) and some more. In the tester, the trace a leads to state s or one of 
its “child states” sa added during the algorithm. In all these states the flag 
LL-reject has the opposite value from divok{s) in AG{Q). 

This means that if the testee process P in the composition has a divergence 
after cr, and if cr is not rejected as an illegal trace, then the parallel composition 
will livelock after cr. If cr is in divtr{Q) (legal divergence), then the LL-reject-flags 
in the states immediately after cr are off, so no error is declared. In the opposite 
case, the tester component is in a livelock rejection state, so an illegal livelock 
will be detected during the computation of the parallel composition. 

Stable Failures We still have the check sfaii (P) C sfail{Q). If (cr, R) G sfaii (P) 
but cr ^ tr{Q), then cr is an illegal trace and will be detected as such. Therefore, 
let us from now on assume that a G tr{Q) but (cr, i?) ^ sfaii (Q). 

Let sp be a stable state of P that can be reached with cr and refuses all 
actions in R. Let R\, . . . , be the maximal refusal sets of Q after cr. Because 
the refusal of R is illegal, for each i, R contains an action Ui that is not present 
in Ri. Thus Oi G S — Ri, and we can reason that each minimal acceptance set of 
AG{Q) after cr contains an action at that is also in R. The mirror image of the 
collection of the minimal acceptance sets contains a subset A of the set of those 
actions, so that A C {oi, . . . , a„}. The tester has a state sa that is reachable 
with cr and offers precisely the actions in A as the next actions. Because sp 
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refuses all of ai, . . . , a„ and both sp and are stable, the parallel composition 
is in a deadlock. Because refusing of R is illegal, we see that S is not a refusal set 
of Q after a, so the collection of minimal acceptance sets is not { 0 }, its mirror 
image is not 0 , and DL-reject(syi) = true. Thus the deadlock is illegal, and the 
error is detected. We have now shown that all illegal stable failures are detected. 

It remains to be proven that if the parallel composition deadlocks while the 
tester is in a deadlock rejection state, then P has an illegal stable failure. The 
deadlock state is of the form (sp, sq), and is reached by some common trace a 
of P and Q. The state sq is either Sfaii, or one of the s^-states added by the 
tester construction algorithm, or one of the original states of AG{Q). If it is Sfaii, 
then already a is illegal. An original state can be a component of a deadlock 
state only if it has no r-transitions to the s^^-states. This is possible only if 
Mirror{accsets{sQ)) = 0 , in which case accsets^sq) = { 0 }, so DL-reject(sg) = 
false, and no error is reported. Therefore, assume from now on that sq is one 
of the s^-states. It corresponds to some set A in Mirror {accsets(sQ)) . By con- 
struction, A contains at least one action from each minimal acceptance set of Q 
after a. Thus for each refusal set Ri, 1 < i < n, of Q after a there is Qi G A 
such that Qi ^ Ri- However, because (sp, sq) is a deadlock, sp refuses all of op 
Thus Sp refuses {ai, . . . , a„} that is not a refusal set of sq. 



4.5 Implementation Considerations 

The tester construction algorithm is otherwise quite straightforward to imple- 
ment, but it contains operations on sets of subsets of S. Choosing appropriate 
data structures is important for fast set operations. The most effective set rep- 
resentation in a typical computer depends on the size of S. For a small S a bit 
vector representation is most efficient. 

Excluding the handling of the acceptance sets (the “for each A G M” loop and 
the preceding line, which does set mirroring), the complexity of the algorithm is 
of the order |£'||S'|. The cost of processing the acceptance sets, and the number 
of the states and transitions in the constructed tester, depend greatly on the 
results of the acceptance set mirroring. If the average number of sets in the 
mirror images is high, then the resulting tester will be large. 

Suppose E = {oi,a2, . . . ,a2n}, where ^ aj whenever i ^ j. Then some 
state may have the acceptance sets A = {{ai, 02}, {03, 04}, . . . , {a2n-i, 02n}}. 
Because all the elements in these n sets are different, the mirror image will be 
{oi, 02} X {03, 04} X • • • X {a2n-i, a,2n}- The number of these sets is 2 ” or 2 ‘-~\ 
Therefore, any algorithm for computing the mirror image has a worst-case ex- 
ponential run time with respect to the size of E. 

A brute-force method for computing Mirror{{Ai, A2, ■ ■ ■ ,A„}) is to first 
compute the Cartesian product Ai x A2 x • • • x A„. The result is formally a set 
of vectors, but these vectors can be converted into sets by dropping the duplicate 
elements and disregarding the order of elements. Then we only have to find the 
minimal ones among these sets. This can be done simply by comparing each set 
to all the others and removing the set if any of its proper subsets is found. 
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The computation of a long chain of Cartesian products can be done one 
product at a time. In this case the computation can be optimized by checking 
for minimality already at this stage, and discarding sets which have subsets in 
the already-computed result. 



4.6 Measurements 

The tester construction algorithm has been implemented as an extension to 
the “Advanced Reachability Analysis” verification tool set [17]. The following 
measurements are intended to give only a rough estimate of the time consumed 
by the tester construction algorithm starting from the acceptance graph. The 
time indicated includes inputting the acceptance graph from a file, constructing 
the tester and outputting the result into a file. The measurements were made on 
a Sun SPARCStation 5 with a 70MHz spare CPU. The time program provided 
with the operating system (Solaris 2.5) was used to measure program run times. 
The first test case is a simple artificial example LTS, the second case is a model 
of the alternating bit protocol with buffers and the third test case is an incorrect 
version of the same protocol. 



Test case 


Simple 


ABP 


BABP 


Size of r 


5 


5 


13 


Specification AG 


Size of S 


5 


150 


1500 


Size of A 


7 


270 


3600 


Tester LTS 


Size of S 


10 


310 


4100 


Size of A 


30 


750 


21000 


CPU time used 


0.2s 


1.7s 


31s 


Real time used 


0.4s 


1.9s 


32s 



5 Conclusions 

We have developed an on-the-fly CFFD-preorder verification method which is 
based on tester processes. Tester processes are ordinary LTSs extended with three 
kinds of error detection states: reject, reject if deadlock, and reject if livelock. 
The implementation process is represented as an LTS or a parallel composition 
of several LTSs. The specification LTS is converted into a tester by determin- 
ising, mirroring of the refusal information, adding new states and r-transitions, 
and declaring certain states as error detection states. Implementation errors 
according to <cpfd can be detected on-the-fly with an ordinary LTS parallel 
composition algorithm augmented with three relatively easy checks based on 
the local state of the tester. The check for livelocks uses an algorithm that has 
been published earlier, [6] or [20]. 

The use of testers requires computationally expensive things to be done only 
to the specification LTS. A software tool for computing these tester processes 
from specification LTSs has been implemented. 
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Abstract. Bisimulations enjoy numerous applications in the analysis of 
labeled transition systems. Many of these applications are based on two 
central observations: first, bisimilar systems satisfy the same branching- 
time properties; second, bisimilarity can be checked efficiently for finite- 
state systems. The local character of bisimulation, however, makes it 
difficult to address liveness coircerns. Indeed, the definitioirs of fair bisim- 
ulation that have been proposed in the literature sacrifice locality, and 
with it, also efficient checkability. We put forward a new definition of fair 
bisimulation which does not suffer from this drawback. 

The bisimilarity of two systems can be viewed in terms of a game played 
between a protagonist and an adversary. In each step of the infinite 
bisimulation game, the adversary chooses one system, makes a move, and 
the protagonist matches it with a move of the other system. Consistent 
with this game-based view, we call two fair transition systems bisimilar 
if in the bisimulation game, the infinite path produced in the first system 
is fair iff the infinite path produced in the second system is fair. 

We show that this notion of fair bisimulation enjoys the following proper- 
ties. First, fairly bisimilar systems satisfy the same formulas of the logics 
Fair-AFMC (the fair alternation-free /r-calculus) and Fair-CTL*. There- 
fore, fair bisimulations can serve as property-preserving abstractions for 
these logics and weaker ones, such as Fair-CTL and LTL. Indeed, Fair- 
AFMC provides an exact logical characterization of fair bisimilarity. Sec- 
ond, it can be checked in time polynomial in the number of states if two 
systems are fairly bisimilar. This is in stark contrast to all trace-based 
equivalences, which are traditionally used for addressing liveness but re- 
quire exponential time for checking. 



1 Introduction 

In system analysis, a key question is when two systems should be considered 
equivalent. One way of answering this question is to consider a class of queries 
and to identify those systems which cannot be distinguished by any query from 
the considered class. Queries typically have the form “does a system satisfy 
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a requirement specified in a given logic?” If one considers finite behaviors of 
systems, then a useful model is the labeled transition graph, whose states or 
transitions are labeled with observations, and the finest reasonable equivalence 
on labeled transition graphs is bisimilarity [Par80,Mil89]. On one hand, no 
calculus query, no matter how complex, can distinguish bisimilar systems. On 
the other hand, bisimilarity is not too fine for constructing an abstract quo- 
tient system if branching-time properties are of interest. This is because simple 
Hennessy-Milner queries, which correspond to the quantifier-free subset of the 
^-calculus, can distinguish systems that are not bisimilar. 

If one wishes to consider infinite limit behaviors also, then the labeled tran- 
sition graph needs to be equipped with fairness constraints. The most common 
fairness constraints have either Biichi form (requiring that a transition cannot 
be enabled forever without being taken) or Streett form (requiring that a tran- 
sition cannot be enabled infinitely often without being taken) . If we can observe 
whether a transition is enabled or taken — that is, if the query logic can re- 
fer to these events — then bisimilarity still captures the equivalence induced by 
branching-time queries. However, if, as is often the case in system design, the 
private (i.e., unobservable) part of the system state contributes both to whether 
a transition is enabled and to the result of the transition, then bisimilarity is too 
coarse for branching-time queries. For example, if we ask whether a system has 
an infinite fair behavior along which some observation repeats infinitely often, 
then the answer may be Yes and No, respectively, for two bisimilar systems, 
because infinite behaviors may be identical in their observations yet different 
in their fairness. (One should note that one solution, albeit a nonoptimal one, 
is simply to define bisimilarity with respect to an extended set of observations 
whose new elements make fairness observable. This solution is nonoptimal as the 
resulting “extended-bisimilarity” relation is generally too fine: there can be sys- 
tems that are not extended-bisimilar, yet cannot be distinguished by queries that 
refer to the newly introduced observations in a restricted way, namely, only for 
checking if an infinite behavior is fair. An example of this is given in Section 5). 

It is therefore not surprising that generalized notions of bisimilarity have been 
proposed which take into account fairness constraints. These notions generally 
have in common that they start from a query logic, such as Fair-CTL [ASB+94] 
or Fair-CTL* [GL94] (where all path quantifiers range over fair behaviors only), 
and define the equivalence induced by that logic: two systems are equivalent 
iff no query can distinguish them. Unfortunately, the resulting equivalences 
are unsuitable for use in automatic finite-state tools, because checking equiv- 
alence between two systems is either not known to be polynomial (for Fair- 
CTL based bisimilarity) or known to be PSPACE-hard (for Fair-CTL* based 
bisimilarity) in the combined number of states [KV96]. This is in stark contrast 
to the unfair case, where bisimilarity for finite-state systems can be checked 
efficiently [PT87,KS90,CPS93]. 

Borrowing ideas from earlier work on fair simulations [HKR97] , we show that 
a fair refinement of bisimilarity can be defined which (1) corresponds to a natural 
query logic and (2) can be checked efficiently. Our starting point is the game- 
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based view of bisimilarity. The bisimilarity of two systems can be viewed in terms 
of a two-player game between a protagonist and an adversary. In each step of the 
game, the adversary chooses one of the systems together with a transition, and 
the protagonist must match the resulting observation by a transition of the other 
system. The game proceeds either until the protagonist cannot match, in which 
case the adversary wins, or for an infinite number of steps, in which case the 
protagonist wins. If the adversary has a winning strategy, then the two systems 
are not bisimilar; if the protagonist has a winning strategy, then the systems 
are bisimilar. In the presence of fairness constraints, we generalize this game 
as follows. If the bisimulation game is played for a finite number of steps, then 
the adversary wins as before. However, if the bisimulation game is played for an 
infinite number of steps, then the winner is determined differently. If the infinite 
paths traversed in the two systems are either both fair or both unfair, then the 
protagonist wins; otherwise the adversary wins. In other words, the objective of 
the protagonist is not only to match observations but also to match both the 
satisfaction and the violation of fairness constraints. 

In Section 2, we define our notion of fair bisimilarity formally and show that 
it is finer than the previously proposed notions; that is, it distinguishes states 
that cannot be distinguished by Fair-CTL*. The main benefit of our definition 
is its efficient implementability in finite-state tools: it can be checked in time 
polynomial in the combined number of states if two systems are fairly bisimilar 
according to our definition. A tree-automata based algorithm is given in Section 3 
together with its complexity analysis. In Section 4, we prove that two systems 
with Biichi or Streett constraints are fairly bisimilar, in our sense, iff they sat- 
isfy the same formulas of Fair-AFMC (the fair alternation- free /i-calculus) . It 
follows that Fair-AFMC provides an exact logical characterization and a query 
language for our fair bisimilarity. Finally, in Section 5, we discuss several issues 
in constructing system abstractions using fair-bisimilarity quotients. 

Related work. In process algebra, several preorders and equivalences on la- 
beled transition systems have been defined to account for fairness and have been 
studied from axiomatic and denotational angles [BW90,HK96]. That line of re- 
search usually considers fairness in the context of divergence (infinitely many 
silent T actions). By contrast, our model has no silent actions, and our notions 
of Biichi and Streett fairness are inspired from oj automata. Also, our focus is 
on efficient algorithms. In contrast, all fair preorders based on failures [BK087] 
and testing [Hen87,VEB95,NC95] are closely related to fair trace containment, 
and the problems of checking them are hard for PSPACE. 

2 Defining Fair Bisimilarity, Game-Theoretically 

A (Kripke) structure is a 5-tuple K = {E,W,w, R, L) with the following com- 
ponents: 

— A finite alphabet E of observations. Usually, we have a finite set P of propo- 
sitions and E = 2^ . 
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— A finite set W of states. 

— An initial state w € W. 

— A transition relation R C W x W. 

— A labeling function L :W ^ A that maps each state to an observation. 

The structure K is deterministic if whenever i?(w, wi) and R(w, W2) for w\ W2, 
then L(wi) 7^ L(w2)- For a state w S W, a w-run of iF is a finite or infinite 
sequence w = wq -wi ■W2 ■ ■ ■ of states Wi G W such that wq = w and R{wi, Wi+i) 
for all i > 0. If w = wq ■ wi ■ W2 ■ ■ ■ Wn then |mJ| is n. If w is infinite, then |w| is 
uj. We write inf(wJ) for the set of states that occur infinitely often in w. A run 
of AT is a rh-run, for the initial state w. Let a be the a finite or infinite sequence. 

A fairness constraint for K Is a function that maps every infinite run of K 
to the binary set {/air, unfair}. We consider two kinds of fairness constraints: 

— A Biichi constraint F is specified by a set Fb C W of states. Then, for 
an infinite run w of AT, we have F(W) = fair iff inf(l(J) H Fb yf 0 . Biichi 
constraints can be used for specifying the weak fairness of transitions (e.g., 
a transition is infinitely often either taken or disabled). 

— A Streett constraint F is specified by a set Fg C 2 '^ x 2 '^ of pairs of state 
sets. Then, for an infinite run w of A', we have F(fw) = fair iff for every pair 
(Z,r) e Fs, if inf(zU) n Z 7^ 0 then inf(w) n r 7^ 0 . Streett constraints can be 
used for specifying the strong fairness of transitions (e.g., if a transition is 
infinitely often enabled, then it is infinitely often taken). 

A fair structure 1C = (AT, F) consists of a structure K and a fairness constraint F 
for AT. The fair structure /C is a Biichi structure if A is a Biichi constraint, and 
/C is a Streett structure if A is a Streett constraint. In particular, every Biichi 
structure is also a Streett structure. For a state w G W, a fair w-run of /C is 
either a finite w-run of K or an infinite w-run w of K such that A(w) = fair. A 
fair run of /C is a fair w-run, for the initial state w. 

In the following, we consider two structures Ki = {E,Wi,wi, Ri, Li) and 
K2 = (A, W2, W2, A2, L2) over the same alphabet, and two fair structures ICi = 
(Ai,Ai) and IC2 = (A2,A2). 



Bisimulation 

A binary relation S C Wi x W2 is a bisimulation between K\ and K2 if the 
following three conditions hold [Par 80 ,Mil 89 ]: 

1 . If 5 (wi,W2 ), then Ai(wi) = L2{w2). 

2 . If S'(wi,W2) and i?i(wi,w{), then there is a state w’2 G W2 such that 
i?2(w2,W2) and S{w[,W2). 

3 . If S'(wi,W2) and i?2(w2,wy, then there is a state w[ G Wi such that 
i?i(wi,w{) and S{w[,W2). 

The structures Ki and K2 are bisimilar if there is a bisimulation S between K\ 
and K2 such that S{wi, W2). The problem of checking if K\ and K2 are bisimilar 
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can be solved in time 0((|i?i| + I-R2I) ■ log(|FFi| + 11^21)) [PT87]. The following 
alternative definitions of bisimilarity are equivalent to the definition above. 

The game-theoretic view. Consider a two-player game whose positions are 
pairs (wi, W2) G Wi x W2 of states. The initial position is {wi,W2)- The game is 
played between an adversary and a protagonist and it proceeds in a sequence of 
rounds. In each round, if (wi, W2) is the current position, the adversary chooses a 
structure and makes a move that respects its transition relation. Then, the pro- 
tagonist makes a matching move in the other structure. If the adversary chooses 
to move in Ki, and updates the first component wi to an i?i-successor w[, then 
the protagonist must update the second component W2 to some i?2-successor w'2 
such that Li{w[) = 172(^2). If no such w'2 exists, then the protagonist loses. 
Similarly, if the adversary chooses to move in K2, and updates the second com- 
ponent W2 to an i?2-successor w'2, then the protagonist must update the first 
component wi to some i?i-successor w'l such that Li{w'i) = 172(^2). If no such 
w'l exists, then the protagonist loses. If the game proceeds ad infinitum, for w 
rounds, then the adversary loses. It is easy to see that Ki and K2 are bisimilar 
iff the protagonist has a winning strategy. 

The temporal-logic view. Bisimilarity provides a fully abstract semantics for 
the branching-time logics CTL, CTL*, AFMC (the alternation- free fragment of 
the /i-calculus), and MC (the /r-calculus) [BCG88]. Formally, two structures Ki 
and K2 are bisimilar iff for every formula ip of CTL (or CTL* or AFMC or 
MC), Ki satisfies ip iff K2 satisfies ip. 



Previous Definitions of Fair Bisimulation 

In the literature, we find two extensions of bisimilarity that account for fairness 
constraints. The two extensions are motivated by the branching-time logics Fair- 
CTL and Fair-CTL*, which are interpreted over fair structures with the path 
quantifiers being restricted to the infinite runs that are fair [CES86]. 

CTL-bisimulation [ASB+94]. A binary relation S C W\ x W2 is a CTL- 
bisimulation between JCi and IC2 if the following three conditions hold: 

1. S' is a bisimulation between Ki and K2- 

2 . If S{wi,W2), then for every periodic fair wi-run w = ug -ui -U2 ■ ■ ■ Un- {un+i ■ 
Un+2 ■ ■ ■ Un+k)^ of /Cl, there is a fair ?C2-run w' = u'q ■ u'l ■ u'2 ■ ■ ■ of IC2 such 
that for I < i < n we have S{ui,u[), and for i > n there exists u G inf(w) 
such that S(u, m'). 

3 . If S(wi,W2), then for every periodic fair W2-run w' = u'q-u[-u' 2 ■ ■ ■ u'„- ■ 

’'‘■n+2 ' ' ' '^n+k)‘^ ^2, there is a fair wi-run uJ = uq • ui • U2 • • • of /Ci such 

that for I < / < n we have S{ui,u'^), and for i > n there exists u' G inf(uJ^) 
such that S{ui,u'). 

The fair structures /Ci and /C2 are CTL -6/szmi/ar if there is a CTL-bisimulation S 
between JCi and JC2 such that S{w\,W2)- For Biichi or Streett constraints Fi 
and F2 , the problem of checking if there is a CTL-bisimulation between /Ci and 
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K.2 is known to be in PSPACE. No matching lower bound is known, but the best 
known algorithm has a time complexity exponential in the number of states. Two 
fair structures K.i and IC2 are CTL-bisimilar iff for every formula '0 of Fair-CTL, 
JCi satisfies ij: iff IC2 satisfies ijj [ASB+ 94 ]. 

CTL*-bisimulation [ASB+ 94 ,GL 94 ]. A binary relation S C Wi x W2 is a CTL*- 
bisimulation between JCi and IC2 if the following three conditions hold: 

1 . If S{wi,W2), then Li{wi) = ^2(^2). 

2 . If S{wi,W2), then for every fair wi-run w = uq ■ u\ ■ U2 ■ ■ ■ of /Ci, there is a 

fair W2-run w' = rtg • • U2 ■ ■ ■ of IC2 such that w' S -matches w; that is, 

|uJ'| = |w| and S{ui,u[) for all 0 < i < |w|. 

3 . If S{wi,W2), then for every fair W2-run w' = u'q ■ u'l ■ u'2 ■ ■ • of /C2, there is a 
fair wi-run w = uq ■ u\ ■ U2 ■ ■ • oi K.\ such that w' S-matches w. 

Every CTL*-bisimulation between /Ci and IC2 is a bisimulation between K\ 
and K2- The fair structures /Ci and IC2 are CT\j* -hisimilar if there is a CTL*- 
bisimulation S between /Ci and IC2 such that S{wi,W2)- For Biichi or Streett 
constraints Fi and F2, the problem of checking if there is a CTL*-bisimulation 
between JCi and JC2 is complete for PSPACE. In particular, the problem is 
PSPACE-hard in the combined number \Wi\ + IW2I of states [KV 96 ]. Two fair 
structures K.i and JC2 are CTL*-bisimilar iff for every formula tp of Fair-CTL*, 
/Cl satisfies tp iff ^2 satisfies ip [ASB+ 94 ,CL 94 ]. 

CTL*-bisimilarity is strictly stronger than CTL-bisimilarity [ASB+ 94 ]. For- 
mally, for all fair structures /Ci and /C2, if /Ci and /C2 are CTL*-bisimilar, then /Ci 
and IC2 are CTL-bisimilar. Moreover, there are two Biichi structures /Ci and IC2 
such that /Cl and IC2 are CTL-bisimilar, but /Ci and IC2 are not CTL*-bisimilar. 
This is in contrast to the unfair case, where CTL and CTL* have the same 
distinguishing power on Kripke structures. 



Our Definition of Fair Bisimulation 

Let /Cl and IC2 be fair structures. Recall the bisimulation game played between 
the adversary and the protagonist. A strategy t is a pair of functions, t = 
{t\tT2), where n is a partial function from {W\ x W2)* x Wi to W2, and T2 is 
a partial function from {W\ x W2)* x W2 to Wi. The strategy is used by the 
protagonist to play a game against the adversary. The game proceeds as follows. 
The game starts at some position in Wi x W2. If the game so far has produced 
the sequence tt € {W\ x W2)* of positions, and {u,u') is the last position in tt, 
the adversary has two sets of choices. It can move either in Ki or in K2- If the 
adversary moves to w in Ki, such that R\{u^w), then the first component t\ of 
the strategy instructs the protagonist to move to w' = ri( 7 r, w), where i?2(u', w'), 
thus resulting in the new position pw,w'). If the adversary moves to w' in K2, 
such that R2{u',w') then the second component T2 of the strategy instructs 
the protagonist to move to w = T2 (tt,w'), where Ri{u,w), thus resulting in 
the new position {w,w'). A finite or infinite sequence w is an outcome of the 
strategy r if W results from letting the adversary make an arbitrary move at 
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each step, and making the protagonist respond using r in each step. Formally, 
w = {wq,Wq) ■ (wi,w[) • • • S {W\ X W2)* U {W\ X W2Y is an outcome of the 
strategy r if for all 0 < i < |wJ|, either (1) = ti((u>o, w'q) ■ ■ ■ {wi,w[) ■ Wi+i), 

or ( 2 ) Wi+i = T2 {{wq,Wq) ■■■ {wi,w[) ■ w'+i). 

A binary relation S C W\ x W2 is a fair hisimulation between /Ci and /C2 if 
the following two conditions hold: 

1. If S{w,w'), then Li{w) = L2{w'). 

2. There exists a strategy r such that, if S{u,u'), then every outcome w = 

(wq^Wq) ■ - of T with wq = u and Wq = u' has the following 

two properties: (1) for all 0 < i < |mJ|, we have S{wi,w'f), and (2) the 
projection wq ■ wi ■ ■ ■ of uJ to W\ is a fair wo-run of ICi iff the projection 
Wq ■ w{ - ■ ■ of wJ to W2 is a fair Wg-run of K.2- 

Every fair bisimulation between /Ci and IC2 is a bisimulation between Ki and K2- 
The fair structures /Ci and IC2 are fairly bisimilar if there is a fair bisimulation S 
between ICi and JC2 such that S{wi,W2)- In Section 3 we give an efficient (polyno- 
mial in the combined number of states) algorithm to check if two fair structures 
are fairly bisimilar. For two fair structures /Ci and IC2, we show in Section 4 that 
/Cl and JC2 are fairly bisimilar iff for every formula of Fair-AFMC, /Ci satis- 
fies ip iff IC2 satisfies ip. The following propositions state that fair bisimilarity is 
stronger than CTL*-bisimilarity. 

Proposition 1. For all fair structures ICi andlC2, ifICi and IC2 are fairly bisim- 
ilar, then /Cl and JC2 are CTF* -bisimilar. 

Proposition 2. There are two Biichi structures /Ci and IC2 such that /Ci and 
IC2 are CTL* -bisimilar, but /Ci and IC2 are not fairly bisimilar. 

Proof. Consider the Biichi structures /Ci and IC2 shown in Figure 1 (the Biichi 
states are marked). Consider the relation S C Wi x W2, where S = {(w,w') | 
w € Wi,w' € W2, and Li{w) = L2{w')}. It can be checked that S' is a CTL*- 
bisimulation between /Ci and /C2. Consider the bisimulation game starting at 
position (si, ti). The adversary first chooses to move in /C2 and moves to t'f. The 
protagonist can respond by moving to either S2 or s^. If the protagonist moves 
to S2, then the adversary switches to /Ci and moves to S3, forcing the protagonist 
to move in IC2 to t'f. If the protagonist moves to s'2, then the adversary switches 
to /Cl and moves to S4, forcing the protagonist to move in /C2 to t'f. In both cases, 
the game goes back to the initial state (si,ii) in the next round. By repeating 
this sequence ad infinitum, the adversary ensures that the run produced in /Ci 
is fair, while the run produced in /C2 is not. Thus /Ci and IC2 are not fairly 
bisimilar. □ 

Our game-theoretic definition of fair bisimulation is inspired by the notion 
of fair simulation from [HKR97]. It should be noted that, as in the unfair case, 
fair bisimulation is stronger than mutual fair simulation. Consider again the two 
structures in Figure 1. Then /Ci fairly simulates /C2 and IC2 fairly simulates /Ci, 
despite the fact that /Ci and IC2 are not fairly bisimilar. It should also be noted 
that, in the example of Figure 1, the adversary needs to switch between /Ci and 
/C2 infinitely often to win the fair-bisimulation game. 
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3 Checking Fair Bisimilarity, Efficiently 

We present an algorithm for checking if two fair structures are fairly bisimilar. 
The time complexity of our algorithm is polynomial in the combined number of 
states. The algorithm exploits properties of a weak version of fair bisimulation, 
where the game is required to start at the initial states. 



Init-fair Bisimulation 

A binary relation S C Wi x W2 is an init-fair bisimulation between K-i and IC2 
if the following three conditions hold: 

1 . S{Wi,W2). 

2 . If S{s,t), then Ti(s) = L2{f). 

3 . There exists a strategy r such that every outcome w = {wq, Wq) ■ (wi,w{) ■ ■ ■ 
of r with Wo = wi and Wg = UI2 has the following two properties: ( 1 ) for all 
0 < i < |w|, we have S{wi, w'f), and ( 2 ) the projection wg -wi • • • of w to Wi 
is a fair run of /Ci iff the projection Wq • wj • • • of W to W2 is a fair run of K.2- 

The fair structures /Ci and JC2 are init-fairly bisimilar if there is an init-fair 
bisimulation S between /Ci and /C2. Every fair bisimulation S between ICi and IC2 
with S{wi,W2) is also an init-fair bisimulation between /Ci and IC2, but not every 
init-fair bisimulation is necessarily a fair bisimulation. Init-fair bisimulations are 
useful to us because of the following monotonicity property. 
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Proposition 3 . For all fair structures JC\ = {Ki,Fx) and JC2 = (^^2,^2), if S 
is an init-fair bisimulation between K,\ and IC2, and S' S is a bisimulation 
between K\ and K2, then S' is also an init-fair bisimulation between ICi and K.2- 

Moreover, checking for the existence of a fair bisimulation can be reduced to 
checking for the existence of an init-fair bisimulation. 

Proposition 4 . For all fair structures K-i = (Ki,Fi) and JC2 = (K2,F2), ICi 
and IC2 are init-f airly bisimilar iff K,\ and IC2 are fairly bisimilar. 

The proofs of both propositions are similar to the simulation case [HKR 97 ]. 



The Algorithm 

Given two structures Ki = {S,Wi,w\,R\,Li) and K2 = {S,W2,'W2, R2, L2), 
and two fair structures ICi = {Ki,Fi) and K.2 = (^2,^2), we present an 
automata-based algorithm that checks, in time polynomial in K\ and K2, 
whether there is a fair bisimulation between /Ci and K.2- 

A coarsest bisimulation between Ki and K2 is a binary relation S C Wi x 
W2 such that ( 1 ) S is a bisimulation between Ki and K2, and ( 2 ) for every 
bisimulation S between Ki and A2, we have S C S. The following proposition, 
which follows from Propositions 3 and 4 , reduces the problem of checking if there 
is a fair bisimulation between Ki and K2 to checking if the (unique) coarsest 
bisimulation between Ki and K2 is an init-fair bisimulation between Ki and K2 ■ 

Proposition 5. For all fair structures Ki = {Ki,Fi) and K2 = (^ 2 ,^ 2 ); if 
S is the coarsest bisimulation between K\ and K2, then K\ and K2 are fairly 
bisimilar iff S is an init-fair bisimulation between K\ and /C2. 

The coarsest bisimulation between K\ and K2 can be constructed in time 
0 ((|i?i| -I- |i?2|) • log(|kPi| -I- |kP2|)) using the Paige- Tarjan algorithm [PT 87 ]. 
Hence, we are left to find an algorithm that efficiently checks, given a relation 
S C Wi X W2, if S is an init-fair bisimulation between Ki and K2- For this 
purpose, consider the structure Ks = {Es^W,w^R,L) with the following com- 
ponents: 

— Es = Wi U W2- Thus, each state of Ks is labeled by a state of Ki or A2. 

— FT = (Sx {a})U(FFi x W2 x { 1 , 2 } x {p}). Thus, there are two types of states: 
adversary-states, in which the FFi-component is related by S to the W2- 
component, and protagonist-states, which are not restricted. We regard the 
states of Ks as positions in a game, with the adversary moving in adversary- 
states and the protagonist moving in protagonist-states. Since the adversary 
can choose to move either in K\ or in K2, we record this choice in the 
protagonist states. If the third component of a protagonist state is 1 ( 2 ), 
then the protagonist needs to make a move in K2 (Afi). 

— w = {wi,W2, bl) . This is the initial game position. 
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- i? = {((wi,W2,a),(wi,-u;2,l,p)) | i?i(wi, u>;)}U {((wi, ^2, a), (wi, W 2 , 2, p)) 

I i? 2 (w 2 ,W 2 )} U {((wi,W 2 , 2 ,p), (w;,W 2 ,a)) I U{((wi,W 2 ,l,p), 

(wi , ^2 , a) ) I i?2(u>2, Thus, the adversary and the protagonist alternate 
moves. The adversary moves along transitions that correspond to transitions 
of either K\ or K2- If the adversary makes a move along a transition of K\ 
(it'2), the protagonist must reply with a move along a transition of K2 (Ki). 
Since adversary-states consist only of pairs in S, the protagonist must reply 
to each move of the adversary with a move to a state {wi , W2 , a) for which 
S{WI,W 2 ). 

— We label an adversary-state by its Wi-component and we label a protagonist- 

state by its W2-component: u>2, a)) = {u>i}, and L{{wi,W2, -jP)) = 

{^2}. 

We say that a run w of Ks satisfies a fairness constraint F if F{L{W)) = fair. 
The protagonist wins the game on K$ if ( 1 ) whenever the game position is a 
protagonist-state, the protagonist can proceed with a move, and ( 2 ) whenever 
the game produces an infinite run of Ks, the run satisfies Fi iff it satisfies F2. 
Then, the protagonist has a winning strategy in this game iff S is an init-fair 
bisimulation between /Ci and /C2. 

The problem of checking the existence of a winning strategy (and the syn- 
thesis of such a strategy) can be reduced to the nonemptiness problem for tree 
automata. We construct two tree automata: 

1 . The tree automaton As accepts all infinite (Wi U W2)-labeled trees that can 
be obtained by unrolling Ks and pruning it such that every adversary-state 
retains all its successors, and every protagonist-state retains exactly one of 
its successors. The intuition is that each tree accepted by As corresponds to 
a strategy of the protagonist. The automaton has 0 (|Wi| • IW2I) states, 
and it has a vacuous acceptance condition. 

2 . The tree automaton Af accepts all {W\ U TT2)-labeled trees in which all 
paths have the following property: Fi is satisfied iff F2 is satisfied. When JCi 
and K.2 are Biichi structures, the automaton Af can be defined as a Streett 
automaton with two states and two pairs in the Streett constraint. When /Ci 
and IC2 are Streett structures, the automaton Af can be defined as a Streett 
automaton with 3(I^iI+I-P’2|) . |Fi| • 1^2! states, and 3 • (|Fi| -|- IF2I) pairs in the 
Streett constraint. 

The protagonist has a winning strategy iff the intersection of the Streett au- 
tomata As and Af is nonempty. To check this, we define and check the 
nonemptiness of the product automaton As x Af- Since As has a vacuous 
acceptance condition, the product automaton is a Streett automaton with the 
same number of pairs as Af- Finally, since checking the nonemptiness of a Streett 
tree automaton with n states and / pairs requires time ■ /!) [KV 98 ], 

the theorem below follows. 

Theorem 1 . Given two fair structures /Ci and IC2 with state sets Wi and W2, 
transition relations Ri and R2, and fairness constraints F\ and F2, we can check 
whether ICi and JC2 are fairly bisimilar in time: 
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— 0((|FFi| • IVF 2 I)®), for Biichi structures. 

— 0(n(2/+i).3(2/'+/)/3./!), where n=\Wi\-\W 2 \-\Fi\-\F 2 \ and f = 3 ■ {\Fi\ + 
IF 2 I), for Streett structures. 

4 Characterizing Fair Bisimilarity, Logically 

We show that fair bisimilarity characterizes precisely the distinguishing power 
of the fair alternation- free /x-calculus (Fair-AFMC). A formula of the ^-calculus 
(MC) is one of the following: 

— true, false, p, or ^p, for a proposition p G P. 

— y, for a propositional variable y gV. 

— tpi V or (fii A (fi 2 , where (pi and ip 2 are MC formulas. 

— 30 ip or VO p, where is a MC formula. 

— py.f{y) or vy.ffy), where f{y) is a MC formula. All free occurrences of the 
variable y in py.f{y) and vy.f{y) are bound by the initial fixpoint quantifier. 

A MC formula is alternation-free if for all variables y G V, there are respectively 
no occurrences of ir (/i) in any syntactic path from a binding occurrence py {vy) 
to a corresponding bound occurrence of y. For example, the formula px.fp V 
py.{x\J 30 y)) is alternation- free; the formula px.{p\J vy.{x/\30 y)) is not. The 
AFMC formulas are the MC formulas that are alternation- free. 

The semantics of AFMC is defined for formulas without free occurrences 
of variables. We interpret the closed AFMC formulas over fair structures, thus 
obtaining the logic Fair-AFMC. Unlike in Fair-CTL and Fair-CTL*, where the 
path quantifiers are restricted to fair runs, the /x-calculus does not explicitly 
refer to paths, and the definition of the satisfaction relation for Fair-AFMC is 
more involved. An AFMC formula can be thought of being evaluated by “un- 
rolling” the fixpoint quantifiers; for example, uy.ffy) is unrolled to f{vy.f(jj)). 
Least-fixpoint (/x) quantifiers are unrolled a finite number of times, but greatest- 
fixpoint (ly) quantifiers are unrolled ad infinitum. In Fair-AFMC, we need to 
ensure that all jz-unrollings are fair. This is done formally using the notion of 
sat-trees. 

The closure cl{tp) of a Fair-AFMC formula ip is the least set of formulas that 
satisfies the following conditions: 

— true e cl{tp) and false G cl{'tp). 

— G cl{-tp). 

— If (^1 A (fi 2 or (fix V ip 2 is in cKpp), then ipi G cl{if) and p 2 V cl{'4i). 

— If 30 ip or VO ip is in cl{if), then ip G cl{if). 

— If py.fiy) G di-tp), then f{py.f{y)) G clipip). 

— If vy.f{y) G d{tp), then f{vy.f{y)) G d{tp). 



Each Fair-AFMC formula specifies a set of “obligations” — a subset of formulas 
in cl{'ip ) — that need to be satisfied. The witness to the satisfaction of a formula 
is a tree called a sat-tree. 
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We first define labeled trees formally. A (finite or infinite) tree is a set t C IN* 
such that if xn G t, for x G IN* and n G IN, then x G t and xm G t for all 
0 < m < n. The elements of t represent nodes: the empty word e is the root of t, 
and for each node x, the nodes of the form xn, for n G IN, are the children of x. 
The number of children of the node x is denoted by deg{x). A path p of t is a 
finite or infinite set p C t of nodes that satisfies the following three conditions: 
(1) e G p, (2) for each node x G p, there exists at most one n G IN with xn G p, 
and (3) if xn G p, then a; G p. Given a set A, an A-laheled tree is a pair {t, A), 
where t is a tree and A : t ^ A is a labeling function that maps each node of t to 
an element in A. Then, every path p = {e, no, n-oni, nonin 2 , . . .} of t generates 
a sequence A(p) = A(e) • A(no) • A(noni) • • • of elements in A. 

Given a fair structure K. = {K,F) with K = {S,W,w,R,L), and a Fair- 
AFMG formula i/', a sat-tree {t, A) of K. for is a {W x c^(V'))-labeled tree (t, A) 
that satisfies the following conditions: 

— A(e) = {w,ip). Thus, the root of the tree, which corresponds to the initial 
obligation, is labeled by the initial state of K and ip itself. 

— If \{x) = (w, false) or \{x) = {w,true), then deg{x) = 0. 

— If A(x) = {w,p), where p € P, then deg{x) = I. If p G L(w), then A(x0) = 
(w,true); otherwise A(a;0) = (w, false). 

— If A(a:) = {w, ~^p), where p G P, then deg{x) = I. If p G L{w), then A(a;0) = 
(w, false); otherwise A(a;0) = (w,true). 

— If \{x) = {w, (fix V (P 2 ), then deg{x) = I and A(a:0) G {{w, pi), {w, ^ 2 )}- 

— If A(a;) = {w,ipi A P 2 ), then deg{x) = 2, A(x0) = and A(a;I) = 

{W,ip2)- 

— If A(x) = (w,30 p), then deg{x) = 1 and A(x0) G {{w' ,(p) \ R{w,w')}. 

— If A(x) = (w,VO p), and {wo,wi, . . . ,rc„} are the successors of w in K, in 
some arbitrary (but fixed) order, then deg{x) = n+1, and for 0 < z < n, we 
have X{xi) = {wi,ip). 

— If A(a;) = {w,vy.f{y)), then deg(x) = 1 and A(a;0) = {w , f (vy . f (y))) . 

— If A(a:) = {w,p,y.f{y)), then deg{x) = I and A(a;0) = {w , f {/ly . f (y))) . 

Gonsider a sat-tree {t, A) of K. for ip. If {t, A) contains no node labeled {w, false), 
then it provides a witness to the satisfaction of all local obligations induced 
by Ip. In addition, we have to make sure that least-fixpoint obligations are not 
propagated forever, and that greatest-fixpoint obligations are satisfied along fair 
runs of /C. Formally, the sat-tree {t, A) of K, for ip is convincing if the following 
three conditions hold: 

1. The sat-tree (t, A) contains no node labeled (zc, false). Thus, all local obli- 
gations induced by tp are satisfied. 

2. For all infinite paths p of {t, A), the projection of A(p) on the cl (V:)-component 
contains only finitely many occurrences of formulas of the form yy.f{y). 
Thus, no least-fixpoint obligation is propagated forever. 

3. For all infinite paths p of {t, A), the projection of A(p) on the VF-component 
satisfies the fairness constraint F of 1C. 
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The fair structure JC satisfies the Fair-AFMC formula tp if there is a convincing 
sat-tree {t, A) of JC for ip. 

If /Cl and /C 2 are not fairly bisimilar, we can construct a Fair-AFMC formula 
Ip such that /Cl satisfies ip and /C 2 does not satisfy ip. Consider the structures 
from Figure 1. The formula VO (30 (cA30 z)V30 (c?A30 z)) is satisfied 
in /Cl and not satisfied in /C 2 . Conversely, if /Ci and /C 2 are bisimilar, and /Ci 
satisifes a Fair-AFMC formula ip, we can use the convincing sat-tree of JCi for 
Ip and the winning strategy of the bisimulation game, to construct a convincing 
sat-tree of JC 2 for ip. 

Theorem 2. For all fair structures JCi and JC 2 , the following two statements 
are equivalent: 

1. /Cl and IC 2 are fairly bisimilar. 

2. For every formula ip of Fair-AFMC, JCi satisfies ip iff IC 2 satisfies ip. 

It is an open problem if the full /i-calculus over fair structures (Fair-MC) can 
be defined in a meaningful way, and to characterize its distinguishing power. In 
particular, condition 2 in the definition of convincing sat-trees for Fair-AFMC 
is no longer appropriate in the presence of alternating fixpoint quantifiers. 

5 Discussion 

An important topic that we have not addressed in this paper is the construction 
of fair abstractions. Here, we discuss some issues and difficulties in doing this. Let 
K = {S, W, w, R, L) be a structure. Let E CW x W he an equivalence relation 
that is observation-preserving, i.e., if E(s,t), then L(s) = L(t). We define the 
quotient of K with respect of E, denoted K/e = {S,W ,w' ,R' ,L'), as follows: 

— The state set is W' = Wj e, the set of equivalence classes of W with respect 
to E. We denote the equivalence class of state w €W hy [w\e- 

— The initial state is w' = [w]e- 

— The transition relation is R' = [w']e) \ R{w,w')}. 

— The labeling function L' is given by L'{\w]e) = L{w). Note that L' is well- 
defined, because E is observation-preserving. 

If S is the coarsest bisimulation between K and K, then K/ s is called the bisim- 
ilarity quotient of K. It is not difficult to check that K and K/s are bisimilar, 
and that K/s is the smallest structure that is bisimilar to K. Since the construc- 
tion of K/s is efficient, it may be a useful preprocessing step for model checking 
CTL, CTL*, and the ^-calculus. 

Let /C = {K, F) be a fair structure. We are interested in finding a fair struc- 
ture 1C which (1) is fairly bisimilar to /C, and (2) has fewer states than /C. Such 
a 1C is an abstraction of 1C which preserves all Fair-AFMC properties, and by 
Proposition 1, also all Fair-CTL* properties. If the construction of 1C is efficient, 
then it may be a useful preprocessing step for Fair-AFMC and Fair-CTL* model 
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/C3: 




(a) abs{IC 3 ) is not min- 
imal 




(b) fabs{K, 4 ,) is not fairly 
bisimilar to 1C 



Fig. 2. Constructing minimal fairly bisimilar abstractions 



checking. We present two attempts at defining IC and point out why neither 
attempt is satisfactory. 

The first attempt makes the fair states observable before constructing a mini- 
mal quotient. This attempt produces a fairly bisimilar abstraction, but not neces- 
sarily a minimal one. Define the binary relation H W xW such that H{w, w') 
iff (1) L{w) = L{w'), and (2) the fairness constraint F treats w and w' identically 
(i.e, if F is a Biichi constraint, then w € F iff w' € F; if F is a Streett constraint, 
then for every Streett pair (l,r), we have w G I iS w' € I, and w G r iS w' G r). 
Clearly, H is an equivalence relation. Let H C W x W he the coarsest bisimu- 
lation between K and K that refines H. Let abs{K) = {Kj where F' is 
obtained by lifting the fairness constraint F to K/ Formally, given a set A C W 
of states, define a{A) = {[w]^ | [w\jj A ^ 0}. If F is a Biichi constraint, let 
F' = a(F); if F is a Streett constraint, let F' = {(a(^),a(r)) | (Z,r) G F}. It 
can be checked that K, and abs{K) are fairly bisimilar. However, abs{K) is, in 
general, not the minimal fair structure which is fairly bisimilar to K,. For exam- 
ple, consider the Biichi structure /C 3 of Figure 2(a). In this example, abs{K^) 
is isomorphic to /C3. But we can merge the states i\ and to produce a fairly 
bisimilar abstraction which has only 5 states, and thus is smaller. 

The second attempt constructs a minimal fair quotient, which is then 
equipped with a fairness constraint. However, there are cases where the straight- 
forward way of equipping the fair quotient with a fairness constraint does not 
result in a fairly bisimilar system. Let S xW he the coarsest fair bisim- 

ulation between K. and JC. Define the relation J (IW xW such that J{w,w') 
iff (1) S{w,w'), and (2) the fairness constraint F treats w and w' identically. 
Clearly, J is an equivalence relation. Let fabs{JC) = {K/j,F'), where F' is ob- 
tained by lifting the fairness constraint F to Kj j. Returning to the structure 
/C 3 of Figure 2(a), we find that fabs{K. 3 ) indeed merges i\ and 14 and produces 
a fairly bisimilar abstraction with 5 states. However, for the Biichi structure /C 4 
of Figure 2(b), fabs^ICi) and /C 4 are not fairly bisimilar. 
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It therefore remains an open problem to construct, in general, a minimal 
structure which is fairly bisimilar to JC (where minimality is measured in the 
number of states). 
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Abstract. We present three methods for the integration of symmetries 
into reachability analysis. Two of them lead to maximal reduction but 
their runtime depends on the symmetry structure. The third one works 
always fast but does not always yield maximal reduction. 
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1 Introduction 

Symmetric structure yields symmetric behavior. Thus, symmetries can be em- 
ployed to reduce the size of reachability graphs for analyzing particular proper- 
ties [HJJJ84,Sta91,ID96] or for model checking [ES96,CEFJ96]. Instead of stor- 
ing all states, only (representatives of) equivalence classes of states are stored. 
There are two major problems that need to be solved in the context of symme- 
tries. Before starting reachability graph generation, we need to investigate the 
symmetries of the system. During graph generation, we need to decide repeat- 
edly whether for a (recently generated) state an equivalent one has been explored 
earlier. 

In the context of high level Petri nets or structured programming languages, 
we can use operations and relations on the data domains or replicated compo- 
nents to describe the symmetries symbolically [HJJ,J84,Jen92]. Then the user 
can provide the description of the symmetries together with the system using 
terms (such as data operations) of the structured language. For instance, having 
the integer numbers as data type, one can map a state where a certain variable 
has value f to a state where that variable has value z -I- 1 . For some classes of 
high level nets or other system descriptions, a symbolic description of a set of 
symmetries can be deduced automatically [CDFH90,Jun98,ID96], though this 
approach seems to be rather sensitive to the syntax used for system descrip- 
tions. Furthermore it is sometimes necessary to model the system very carefully 
to make the symmetries visible to the deduction tool [Chi98,CFG94]. For the 
decision of equivalence between states, one uses the symmetries to transform the 
current state into an equivalent one which is minimal with respect to some, say 
lexicographical, order. The transformed state is called canonical representative, is 
unique, and is used to represent its equivalence class. Currently, this approach is 
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more or less restricted to symmetry groups that can be composed of full permuta- 
tion groups and rotation groups over the involved data domains. As an efficient 
alternative, non-unique representatives have been proposed in [CEFJ96,ID96] 
which potentially lead to a larger graph and some problems for reachability 
tests on the reduced graph. 

Using low level symmetries [Sta91]^ arbitrary symmetry groups can be han- 
dled in a uniform manner as graph automorphisms of the Petri net graph repre- 
sentation. There is no straightforward symbolic description of low level symme- 
tries. Thus, calculation is the only way to get the information about symmetries. 
However, the algorithm proposed in [Sch97] and implemented in INA [RS97] is 
able to calculate polynomially large generating sets of (in worst case exponen- 
tially large) maximal symmetry groups in reasonable space and time. For in- 
stance, the symmetry group calculation for a net with 10000 vertices requires 
usually less than 5 minutes. For nets of that size, reachability analysis is faced 
with a lot of other challenges than symmetry calculation. 

This paper surveys three solutions of the problem of using low level symme- 
tries in reduced graph generation and reports experimental results. 

With the present low level symmetry technology, we fill the following gaps 
left by the symbolic high level calculus: 

— We can deal with systems where a structured representation is not available 
(for instance, translations from other formalisms into low level nets); 

— We offer a fully automated approach to high level (structured) systems with 
small or medium size data domains (prototypes of larger systems) indepen- 
dently of the net inscription syntax; 

— We can handle small or medium size systems having non-standard symmetry 
groups 

2 Petri Nets 

For the purpose of simplicity (in particular due to the immediate correspondence 
between net symmetries and graph automorphisms) , we present the approach for 
place/ transition nets. However, it should not be difficult to transfer the results 
to other formalisms, whether Petri net based or not. 

Definition 1 (Petri net). A tuple N = [P,T, F,W,mo] is a Petri net iff P 
and T are finite, nonempty, and disjoint sets /o/ places and transitions/, F C 
(P X T) U (r X P) (the set of arcs/, W : (P x T) U (T x P) — > N such that 
W{[x,y]) > 0 iff [x,y] G F (the arc multiplicities/, and mo is a state, i.e. a 
mapping mo : P > N. 

^ throughout the paper, we use the term low level for the symmetry approach to 
place/transition nets, i.e. Petri nets with unstructured, uniform tokens. In contrast, 
high level symmetries rely on the ability to use data specific terms for symbolic 
description of symmetries. 
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Throughout the paper, we assume that places and transitions are totally 
ordered. 

For a place or transition x, *x = {y \ [y.,x\ € F} denotes the pre-set of x, 
and X* = {y \ [x, y] G F} denotes its post-set. 

Definition 2 (Transition relation). We say that t ean fire at a state m yield- 
inq state m' [written: m@ > t » m' ) iff for all p G P, m(p) > W{\p,t\) and 
m'{p) = m{p) - W{[p,t]) + W{[t,p\). 

If, for a given state m and transition t there exists a state m' such that 
m@ > t >> m', then we say that t is enabled at m. We extend the transition 
relation to sequences of transitions. Define m@ > e » m for an arbitrary m 
and the empty sequence e, and m@ > wt » m! (w being a transition sequence 
and t a transition) iff there is an m* such that m@ > w » m* and m*@ > 
t » m! . li there is a transition sequence w such that m@ > w » m! , we write 
m@ > * >> m'. 

Definition 3 (Reachability graph). A directed labeled graph is the reachabil- 
ity graph of a Petri net N = [P, T, F, W, mg] iff its set of vertices is the set of 
all reachable states, i.e. {m \ mo@ > * >> m}, and [m,m'] is an edge labeled 
with t iff m@ > t » m' . 

3 Graph Automorphisms 

Consider a directed graph [V, E] (with a finite set V of vertices and a set F C 
V xV oi edges) together with a mapping cf -.V E — > C that assigns a color 
of a set C to every graph element. 

Definition 4 (Graph automorphism). A graph automorphism is a bijection 
a : V V of the vertices of a directed colored graph that respects adjacency and 
coloring, i.e. 

- e=[x,y]G E iff a{e) = [a{x),a{y)] G E; 

— 4>{a-{z)) = 4>{z) for z G V U E . 

The set of all automorphisms of a graph forms a group under composition 
and inversion. The identity is always an automorphism and serves as neutral ele- 
ment of the group. For the remainder of this section, consider an arbitrary graph 
and its automorphism group. There can be exponentially many automorphisms. 
However, there is always a generating set of at most elements for the 

whole automorphism group. In the sequel we consider a rather well formed gener- 
ating set that enjoys a regular structure though it is not necessarily of minimal 
size. The algorithm proposed in [Sch97] returns a generating set as described 
below. Assume a total ordering of V, i.e. V = {ui, . . . , u„}. A well formed gener- 
ating set G for all graph automorphisms consists of jCj families Gi, . . . , G|y|. If, 
for i G {1, . . . , |y|} and j G {i, . . . , |y|}, there exist automorphisms a such that 
cr(vi) = vi, . . . ,a(vi-i) = Vi-i and cr(vi) = Vj then family Gi contains exactly 
one of them. In other words, the elements of family Gi are equal to the identity 
on all vertices smaller than Vi and cover all possible images of Vi. 
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Example 1. Consider the graph depicted in Fig. 1. Every drawn line between 
two vertices x and y corresponds to a pair [x, y] and [y, a;] of edges. Table 1 lists 
a generating set for the 48 graph automorphisms that fits to the rules above. 
The generating set is not minimal. For instance, = (J\o a\. 



Table 1. Generating set of the grid automorphisms 



Argument 


Images 


Family 1 


Family 2 


Family 3 


1 


1 


2 


3 


4 


5 


6 


7 


8 


1 


1 


1 


1 


1 


2 


2 


3 


4 


1 


1 


5 


8 


7 


2 


4 


5 


2 


2 


3 


3 


4 


1 


2 


4 


8 


5 


6 


3 


8 


6 


3 


6 


4 


4 


1 


2 


3 


8 


7 


6 


5 


4 


5 


2 


4 


5 


5 


5 


6 


7 


8 


6 


2 


3 


4 


5 


2 


4 


5 


4 


6 


6 


7 


8 


5 


2 


1 


4 


3 


6 


3 


8 


6 


3 


7 


7 


8 


5 


6 


3 


4 


1 


2 


7 


7 


7 


7 


7 


8 


8 


5 


6 


7 


7 


3 


2 


1 


8 


6 


3 


8 


8 




id 




0-2 


0-3 


t74 


cs 


ce 


(T7 


id 


0-8 


erg 


id 


CIO 



Proposition 1 (Generating set). Every set of automorphisms that fits to the 
rules described above is a generating set for all automorphisms. In particular, 
every automorphism can be represented as the composition a\ o ■ ■ ■ o a\v\ where 
Ui belongs to family Gi of the generating set. 

Proposition 2 (Non— repetition). If for all i, ai and Ti are members of fam- 
ily Gi of a generating set as described above, then a\ o ■ ■ ■ o Un = ti o • • • o 
implies cti = ri , . . . , (T„ = r„ . 

These two propositions state that every automorphism can be generated in 
exactly one way as the composition of one member per family of the generating 
set. As a corollary, the product of the sizes of the families yields the size of the 
automorphism group. For instance, our grid has 8 • 3 • 2 = 48 automorphisms. 
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Rotation groups (automorphism groups of ring-like graphs) have a generating 
set consisting of one family, permutation groups (symmetry groups of clique- 
like graphs) have generating sets where the size of subsequent families of the 
generating set decreases by one. 

4 Petri Net Symmetries 

A Petri net N = [P, T, F, W, mo] can be regarded as colored graph with V = 
P U T, E = F, 4 >(p) = place for p G P, (j)(t) = transition for t G T, and 
Hf) = W^(/) for f € F. 

Definition 5 (Symmetry). A Petri net symmetry is an automorphism of the 
underlying colored graph. 

We denote the symmetry group of a Petri net by S . A symmetry group S 
induces equivalence relations on the Petri net vertices as well as on the states. 

Definition 6 (Equivalence of vertices/states). Two vertices x and y in 

Pur are equivalent with respect to E (x y) iff there is a a G E such that 
a(x) = y. For a state m, let a{m) he the state satisfying, for all x G P U T, 
cr(m)(a(x)) = m(x). A state mi is equivalent to a state m2 with respect to E 
(mi 1TI2) iff there is a a G E such that cr(mi) = m2- 

~i; is an equivalence relation. We denote the ~i; equivalence class containing 
some state m by [mji;. 

5 The Integration Problem 

During generation of the reduced reachability graph, we want to merge equivalent 
states. As soon as a new state m is generated, we compare it against the set of 
already existing states M. If, among those states, there is one equivalent to m, 
we do not store m. Instead, we redirect all arcs to m to the equivalent state. 
Thus, the problem we are confronted with (and which we call the integration 
problem) is: 

Given a symmetry group E, a set M of states, and a state m, decide 
whether there exist an m' G M and a a G E such that a{m) = m' ; in 
the case that such an m' exists, return m' . 

Here, E is given by a well formed generating set. M is the set of already calcu- 
lated states and is usually organized as a search structure (tree, hash table or 
whatsoever) . 

We study three approaches to the integration problem. The first two proce- 
dures implement one of the existential quantifiers appearing in the integration 
problem as a loop. The third method implements the canonical representative 
method to low level Petri nets. 
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6 Iterating the Symmetries 

The integration problem quantifies a symmetry existentially. If we implement 
this quantification as a loop on all symmetries, we obtain the following brute 
force solution: 

FOR ALL cr e 17 DO 

IF cr-i(m) G M THEN 
RETURN yes; 

END; 

END; 

RETURN no; 

The test cr“^(m) G i? is a standard operation on sets of states and can be 
efficiently implemented. So the costs of the procedure depend on the number of 
iterations of the outer loop which is, in the worst case (the case where m is not 
in M), equal to the size of the symmetry group. Due to the up to exponential size 
of symmetry groups, this approach does not work well. However, using decision 
trees for storing the states in M enables a nice reduction concerning the number 
of loops. 

A decision tree treats states as strings and merges common prefixes. Fig. 2 
depicts a decision tree storing the set {(1, 0, 0), (1, 0, 1), (1, 2, 2), (1, 3, 1)}. 

If we find cr“^(m) in the decision tree, we 
exit the loop. Otherwise, there is some prefix 
of a~^{m) that is not contained in the tree 
and the length i of this prefix is available 
through the search process. This means that 
any other state with the same prefix is not 
contained in M as well. However, the 
image of m on the first i places is determined 
by the generators of the first i families of 
the generating set. That is, every symmetry 
that is composed of the same elements of the 
first i families as a, but different elements of 
the last \P\ — i families of the generating set, 
yields the same z-prefix as cr“^(m) and is consequently not contained in M. 
Using this observation, we can skip all such combinations of generators and 
continue with one where at least one of the first i ones is different. This method 
reduces significantly the number of iterations of the outer loop in the above code 
fragment. 

Having implemented this iteration, we found out that the loop reduction was 
powerful enough to make reduced graph generation faster than complete itera- 
tion even if complete iteration runs on an explicitly stored list of all symmetries 
(i.e. re-initialization of the loop is just a jump to the next list element instead 
of composing a symmetry from generators). The current version of INA uses the 
generating set and the described loop reduction. Older versions of INA maintain 



I 




Fig. 2. Decision tree 
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an explicit list of all symmetries. The algorithm works quite well if the symmetry 
group is sparse. Unfortunately, larger symmetry groups require still too many 
iterations of the symmetry loop and graph generation tends to fail. Therefore, 
we need other integration technologies. 

7 Iterating the States 

In this section, we develop another solution of the integration problem where 
the outer loop iterates on states. The principal solution is: 

FOR ALL to' € M DO 

IF 3a : a{m) = m! THEN 
RETURN yes; 

END; 

END; 

RETURN no; 

For the test 3a : a{m) = m! we do not need to iterate the symmetries. The 
algorithm in [Sch97], otherwise used to compute the generating set, can as well 
be customized such that it computes a symmetry mapping m to m! (or recognize 
that such a symmetry does not exist). 

Of course, iterating all states in the outer loop is unacceptable, since there 
are usually too many of them. Fortunately, the number of iterations can be 
reduced significantly when symmetry respecting hash functions are used (the use 
of hash functions has already been studied in [HJ.JJ84]). A hash function assigns 
an index him) from a finite index set I to every state to. This way, the set of 
states M can be partitioned into card{I) classes where two states are in the 
same class iff they have the same hash value. Simple hash techniques store each 
hash class separately such that other search techniques need to be applied only 
to the (hopefully small) hash classes rather than to the complete set of states. 

Symmetry respecting hash functions assign equal hash values to equivalent 
states. Using such a function h, it is sufficient to iterate the subset of M corre- 
sponding to h{m) rather than the whole M. 

As a simple way to get a symmetry respecting hash function, one can use a 
weighted sum of component values. For this purpose, one assigns a number Cp 
to each place p and sets h{m) = ' ™(p) mod k where k is the 

size of the hash table. In order to make this function symmetry respecting, 
one guarantees Cp = Cp> for all equivalent places. The equivalence relation for 
places can be efficiently deduced from the generating set without iterating all 
symmetries. In fact, it is sufficient to start with a family of singleton sets {{p} \ 
p G P} and then to build repeatedly the union of the set containing p with the set 
containing a{p) (for all p G P and all cr of the generating set). This task can be 
efficiently done by Tarjan’s union/find algorithm [Tar75] and produces directly 
the equivalence classes. The implementation used for computing the examples 
at the end of the paper uses weighted component sums as hash function where 
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the Cp are otherwise randomly chosen. Random choice appears to spread hash 
values well enough. 

The proposed method depends on the number of states in M that share the 
same hash value. Besides the general uncertainties of hash functions, there are 
general problems with symmetry respecting hash functions for sparse symmetry 
groups. Consider Fig. 3 and assume that (maybe by some additional hidden net 
structure) the rotations along the ring are the only symmetries. 




Fig. 3. Difficult situation for symmetry respecting hash functions 



In this net, for every pair of outer places there is a symmetry mapping one 
to another. The same holds for inner places. However, there is no symmetry 
mapping an outer place to an inner place. Therefore, a hash function following 
our proposal assigns some weight Co to all outer places and some weight Ci 
to all inner places. Consequently, the best symmetry respecting hash function 
would produce at most 9 different used hash values for the 36 states of the 
symmetrically reduced reachability graph of this net (the hash value depends 
only on how many inner places are marked, but equivalence depends on the 
distances between two marked inner places). In a ring of the same kind but 
length 20, the 52488 states of the reduced graph would share only 21 different 
values of any symmetry respecting hash function (in general, at least — states 
share at most n + 1 hash values). 

A situation as described above is typical for all rotation-like symmetry 
groups. Fortunately, this effect is due to the low number of symmetries (where 
the integration method of the previous section behaves well) . If we use all per- 
mutations between the pi (and corresponding mappings on the U and qi) as 
symmetry group of the system depicted in Fig. 3, the problem does not appear 
since those states that share the same hash value become equivalent. Thus, the 
reduced reachability graph contains only one of them. Assigning, for example. 
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weight 1 to the pi and weight 2 to the qi , we get 9 different hash values for the 9 
states of the reduced reachability graph (in general, n values for n states). Thus, 
iterating the states of a hash class is a method for integrating symmetries that 
displays its best behavior with large symmetry groups. This complements the 
behavior of the method discussed in the previous section. 

8 Canonical Representatives 

This version of symmetry integration is inspired by [HJJ.J84,ID96,CEFJ96]. The 
vector representation of states induces a (lexicographical) order between states: 
Let TO < m' iff there is a place p such that for for all places q {q < p), one has 
m{q) = m'{q) while m{p) < m'(jp). Given this order, every equivalence class of 
states with respect to the symmetry has a least element, called the canonical 
representative. In the version of the integration problem we want to discuss now, 
only canonical representatives are added to M . Then, deciding the integration 
problem consists of transforming the new state to into its canonical represen- 
tative TO and checking whether to is contained in M . So, the transformation of 
arbitrary states into canonical representatives is the bottleneck of this method. 
Efficient solutions of the problem are restricted to few classes of symmetry groups 
(such as rotation or permutation groups). 

The brute force implementation in absence of a symbolic description of the 
symmetries would be to iterate all symmetries and to compare their images of 
the given to. This is, however, not appropriate here since this method would not 
work at all for larger groups. Therefore, we try once more to benefit from the 
structure of the generating set introduced in Sect. 3, in particular from the fact 
that elements of larger families do not change values on the first places. Thus, 
we could try the following procedure to transform states {uij is the j-th member 
of family Gi of the generating set, is the size of family Gi): 

PROCEDURE transform(m:state): state: 

VAR globalmin,localmin: state; 

i,j:Nat; 

BEGIN 

globalmin := to; 

FOR z := 1 TO n DO (* for all families *) 
localmin := globalmin; 

FOR j := 1 TO n DO 

IF (Tij (globalmin) < localmin THEN 
localmin := <7^ (globalmin); 

END 

END 

globalmin := localmin; 

END 

RETURN globalmin; 

END. 
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This procedure has the advantage that it works in polynomial time in the 
size of the net. It has, however, one big disadvantage: it does not always produce 
canonical representatives! For an example, consider the grid example of Sect. 3. 
Assume for the purpose of simplicity that all vertices of the grid are places 
and transform the state m = (1, 2, 2, 3, 3, 2, 1, 3). In the first family, only the 
identity and ae produce 1 on the first place. ae{m) = (1, 3, 3, 2, 2, 3, 1, 2). Thus, 
the minimal state produced by the first family is the state itself. In the second 
family, both ug and erg would produce 3 on the third place, thus m itself remains 
the minimal state. In the third family, ctiq does not change the state. Therefore 
the transform procedure would return m itself. However, applying ug to cre(m) 
leads to (1,2, 2, 2, 3, 3, 1,3) which is smaller than m. Thus, the procedure does 
not always return canonical representatives. The way to the global minimum 
does not always lead via the minima at the intermediate steps of the algorithm. 

The problem is limited to symmetry groups other than rotation and per- 
mutation groups. For rotation groups, we have a generating set consisting of 
a single family containing all symmetries. Thus, no symmetry is forgotten. For 
full permutation groups, the transform procedure performs a real sorting on the 
state. Thus, the global minimum is returned. 

There are two ways out of the problem of non-minimality. The first one would 
be to replace the above transform procedure by one returning the actual canon- 
ical representative. However, the complexity of this problem is closely related 
to deciding graph isomorphism [CEFJ96,ES96] and therefore it is unlikely that 
there is a polynomial solution at all. Therefore we tried the other way which is to 
study which problems arise from non-unique representatives. The first observa- 
tion is that a reduced graph using non-unique representatives can contain more 
than one element of some equivalence classes. Thus, the reduced graph is larger 
than a perfectly reduced one (i.e. one that contains exactly one representative 
per reachable class). On the other hand, most global properties do not depend on 
perfect reduction. In particular, the proof rules described in [.Icn95] for bounded- 
ness, liveness, reversibility and other properties as well as model checking using 
formula respecting symmetries [ES96] are still valid. On the other hand, check- 
ing reachability of a given state m* against a reduced reachability graph might 
be dangerous. It can happen that the transformed image of m* is different from 
all representatives of its equivalence class in the reduced state space. Thus, not 
finding the image of m* in M does not yet mean that the equivalence class of m* 
is not represented in M. The problem can be circumvented in the following way: 
use the canonical representative method for generating the graph, but use one 
of the other methods to check reachability. This compromise should work well 
as long as only some states are to be tested for reachability. 

9 Experiments 

We have implemented all three methods in a new reachability oriented Petri net 
tool called LoLA (Low Level Analyzer). So reduced and full graph generation 
share the same code for all tasks not depending on the integration method. 
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ItSymm corresponds to the iteration of symmetries (Sect. 6), ItState to the 
iteration of states (Sect. 7), and CanRep to the canonical representative method 
of Sect. 8. Times have been taken on a LINUX PC with 64MB RAM and a 
400MHz Pentium processor. The times are written as <minutes>:<seconds>. 
We used a hash table of size 65536. 

The first three tables show the behavior of symmetric reduction for different 
kinds of symmetry groups. We demonstrate the reduction in space, compared 
with full graph generation and give an impression concerning the running time. 
Furthermore we provide experimental evidence for the run time predictions we 
derived in the theoretical sections. There, we expected ItSymm to be fast on 
sparse groups but slow on large groups, we expected ItStates to be slow on 
sparse, but acceptable on large groups, and we expected CanRep to be fast 
anyway but to produce larger graphs. For these goals, small examples should be 
sufficient. 

The first table concerns a deadlocking version of the n dining philosophers 
example. This is an example of a ring-like agents network. 



Table 2. Results for the dining philosophers 





number of phil. 




5 


10 


13 


Places 


25 


50 


65 


Transitions 


20 


40 


52 


States in full graph 


242 


59048 


3"^ - 1 


Edges in full graph 


805 


393650 


? 


Hash entries in full graph 


242 


38048 


? 


Time for full graph 


0:00.085 


0:05.9 


V 


Symmetries 


5 


10 


13 


States in red. graph 


50 


5933 


122642 


Edges in red. graph 


165 


39550 


1062893 


nonempty hash classes in red. graph 


20 


65 


104 


time for ItSymm 


0:00.077 


0:02 


1:38 


time for ItState 


0:00.22 


11:31 


? 


time for CanRep 


0:00.077 


0:01.1 


0:33.5 



The symmetry group is a rotation-like group. Thus, we would store all sym- 
metries explicitly as our generating set. They are organized in a single family. 
Therefore, the canonical representative method must yield full reduction. The 
times of iteration of states and canonical representatives are acceptable. The 
long time for the iteration of states is due to the hashing problem discussed in 
Sect. 7 and makes the method unacceptable for this kind of net. Though the 
times for the reduced graphs include the calculation of the symmetries, they are 
smaller than the corresponding full graph generation. Note that the number of 
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instances of the integration problem to be solved corresponds to the number of 
edges of the reduced graph. 

The second example is a data access scheme where r readers can access some 
data concurrently while w writers access it in mutual exclusion (and excluded 
from the readers). The readers are not distinguishable from each other and the 
writers are not distinguishable from each other. Thus, the symmetry group is 
close to full permutation. 



Table 3. Results for the data access scheme 







readers / writers 






5/5 


13/13 


20/20 


40/40 


Places 


31 


79 


121 


241 


Transitions 


25 


65 


100 


200 


States in full graph 


217 


114857 


21 • { 2 ^''’ + 20) 


41 • (2™ -b 40) 


Edges in full graph 


770 


905554 


? 


7 


Hash entries in full graph 


217 


54952 


7 


7 


Time for full graph 


0:00.1 


2:54 


? 


7 


Generators of Symm. 


20 


156 


380 


1560 


Families of gen. set 


8 


24 


38 


78 


Symmetries 


14400 


13! • 13! 


20! • 20! 


40! • 40! 


States in red. graph 


14 


30 


44 


84 


Edges in red. graph 


82 


470 


1072 


4142 


nonempty hash classes in red. 
graph 


14 


30 


44 


84 


time for ItSymm 


0:00.64 


> 60:00 


7 


7 


time for ItState 


0:00.2 


0:05.8 


0:33 


9:44 


time for CanRep 


0:00.084 


0:00.4 


0:01.7 


0:34 


States generated by CanRep 


17 


41 


62 


122 


Edges generated by CanRep 


85 


481 


1090 


4180 



For this system, iteration of symmetries fails due to the huge number of sym- 
metries even in cases where the full graph can be generated without problems. 
Iteration of states works for this system though it cannot reach the speed of iter- 
ating the symmetries for a rotation symmetry group. However, compared to the 
time needed for the complete graph we can be satisfied with the result. Observe 
that the number of used hash entries shows that every instance of the integra- 
tion problem involves at most one attempt to calculate a symmetry. The fastest 
method is once more the canonical representative approach. However, the exam- 
ple shows that it produces slightly larger graphs. This is due to the interlacing 
of two permutation groups. This problem could be avoided by rearranging the 
order of places which would require knowing the symmetries in advance; but that 
is not the intended application area of the low level Petri net method. However, 
the advantage with respect to time could justify a few more states. Again, one 
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of the perfectly reducing methods and the canonical representative method were 
able to outperform the full graph generation. 

The third example is designed to study the behavior of our procedures on 
grid-like networks. For this purpose we arranged several identical agents in a 
grid network. The agents have two states. The second state can only be entered 
in mutual exclusion to the direct neighbors, controlled by a set of semaphores. 
We vary the number of dimensions of the grid and the number of agents per row 
(our running example would have dimension 3 and two agents per row). 



Table 4. Results for the grid network 





dimensions / agents per row I 




2/5 


3/3 


4/2 


5/2 


Places 


75 


81 


48 


96 


Transitions 


50 


54 


32 


64 


States of full graph 


55447 


70633 


734 


? 


Edges of full graph 


688478 


897594 


5664 


? 


Time for full graph 


0: 10 


0:15 


0:00.18| 


? 


Generators 


4 


10 


21 


41 


Nontrivial families 


2 


3 


4 


5 


Symmetries 


8 


48 


384 


3840 


States of red. graph 


7615 


2352 


21 


332 


Edges of red. graph 


94850 


29912 


172 


4937 


nonempty hash entries of red. 
graph 


192 


106 


9 


17 


Time for ItSymm 


0:03.8 


0:03.7 


0:00.18 


0:26.6 


Time for ItState 


12:29 


4:38 


0:00.72 


1:20 


Time for CanRep 


0:04.7 


0:04.9 


0:00.15 


0:27 


States gen. by CanRep 


15138 


10832 


29 


3032 


Edges gen. by CanRep 


188706 1 


137345 1 


234 


44650 



For this example, the a lot of symmetries can be skipped during the iteration 
of symmetries in ItSymm, so ItSymm is even able to outperform the canonical 
representative method (which has, in addition, the disadvantage of generating 
more states). The grid symmetries can be considered as a sparse symmetry group, 
which explains the bad behavior of ItState. The reason for the slow ItState can 
be found in the small number of used hash classes compared with the large 
number of states. 

The grid example demonstrates the benefits of using low level net symmetries 
on non-standard symmetry groups. In the 3~dimensional case we have 48 sym- 
metries. The size of the reduced graph is approximately 30 times smaller than 
the full one. Since every equivalence class of reachable states should appear in 
the reduced graph, and the size of an equivalence class is bounded by the number 
of symmetries, a reduced graph can never be smaller than the size of the full 
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graph divided by the number of symmetries. As outlined in [CFG94,CDFH90], 
the symbolic symmetry approach based on rotation and permutation groups con- 
siders only a rotation (sub-)group of grid structures that consists only of four 
symmetries. Thus, instead of a reduction factor 30, a reduction factor smaller 
than 4 is achieved. 

The symmetry approach has been criticized for its lack of practical feasibility. 
Extrapolation of the previous tables to larger examples supports this criticism. In 
particular, sparse symmetry groups do not yield sufficient reduction to keep pace 
with the growth of the reachability graph. However, things look different if we 
take into consideration that symmetries can be applied jointly with several other 
reduction techniques, for instance the stubborn set method [Val88]. Benefits 
of combined application have been reported earlier [Yaffil, DBDS93,EJP97]. We 
report results for our particular symmetry approach. Applying symmetries alone 
leads to memory overflow on all reported instances, not to mention full graphs. 



Table 5. Stubborn sets versus stubborn sets with symmetries (for the dining 
philosophers) 







number of phil. 






100 


200 


300 


900 


Places 


500 


1000 


1500 


4500 


Transitions 


400 


800 


1200 


3200 


States in full graph 


- 1 


3''"" - 1 


3^““ - 1 




Symmetries 


100 


200 


300 


900 


States in symm./stubb. red. graph 


299 


599 


899 


2699 


Edges in symm./stubb. red. graph 


496 


996 


1496 


4496 


time for ItSymm-|- stubborn 


0:02 


0:10 


0:26 


7: 00 


States in stubb. red. graph 


29702 


119402 


overflow 


- 


Edges in stubb. red. graph 


39700 


159400 


- 


- 


Time for stubb. red. graph 


0:05 


1:08 


- 


- 



In the grid example, stubborn sets do not reduce the number of states. Con- 
cerning the data access scheme (40 readers/40 writers), stubborn sets produce 
121 states while combined application of stubborn sets and symmetries leads to 
4 states, independently of the number of readers and writers. 

10 Conclusion 

We have presented three solutions of the integration problem (deciding whether 
for the current state there is a symmetrical one in the set of already computed 
states). All methods have their advantages and disadvantages. The advantage 
of the iteration of symmetries and iteration of states is that they yield a com- 
pletely reduced graph. Unfortunately they work well only on sparse (iteration 
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of symmetries) or large (iteration of states) symmetry groups. The canonical 
representative method is the fastest method that works for all kind of symme- 
tries, but it often produces more than one representative for some equivalence 
classes of states. The canonical representative method cannot be used for test- 
ing the reachability of states. This problem can be repaired by using one of the 
other method for testing the reachability on a graph produced by the canonical 
representative method. 

With the set of methods presented in this paper, low level symmetries are 
no longer a restricting factor for reduced reachability graph generation. In most 
cases, the remaining size of the reduced graph limited the analysis. This in turn 
is due to the limitation of the symmetry approach as it and not due to its low 
level version (low level symmetries do not produce larger graphs than high level 
(symbolic) symmetries). 

In connection with other reduction techniques (such as stubborn sets) , much 
larger systems can be analyzed than using either method in isolation. The easy 
use of maximal symmetry groups other than rotation and permutation groups 
is another argument in favor of the low level symmetry approach. 
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Abstract Gurevich’s Abstract State Machines (ASM) constitute a high- 
level specification language for a wide range of applications. The existing 
tool support for ASM-currently including type-checking, simulation and 
debugging-should be extended to support computer-aided verification, 
in particular by model checking. In this paper we introduce an interface 
from our existing tool environment to the model checker SMV, based 
on a transformation which maps a large subset of ASM into the SMV 
language. Through a case study we show how the proposed approach can 
ease the validation process. 



1 Introduction 

Gurevich’s Abstract State Machines (ASM) [7] constitute a simple but powerful 
method for specifying and modeling software and hardware systems. Existing 
case studies include specifications of distributed protocols, architectures, em- 
bedded systems, programming languages, etc. (see [1] and [8]). 

The advantage of ASMs is in the simple language and its intuitive under- 
standing. The method is based on general mathematics which allows to naturally 
model systems on a suitable level of abstraction. Traditionally, the verification 
task is done by means of hand- written mathematical proofs. Tool support for 
the verification process is obviously needed for a broader acceptance. 

Our contribution to this task is the development of an interface between the 
ASM Workbench [2] and the SMV model checker [11]. The ASM Workbench 
is a tool environment, based on a typed version of ASM, which includes a type 
checker and a simulator for ASMs. SMV has been chosen as a typical representa- 
tive of a class of model checkers based on transition systems and could be easily 
replaced by any other similar model checker, e.g., SVE [5] or VIS [6]. 

On the other hand our transformation tool supplies SMV with a higher level 
modeling language, namely ASMs. This facilitates the specification task by al- 
lowing the use of more complex data types and of n-ary dynamic functions for 

* Partially supported by the DFG Schwerpunktprogramm “Softwarespezifikation” . 
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parameterization (a peculiar feature of the ASM language, which generalizes the 
classical notion of state variables). 

Since model checking is only applicable to finite-state systems, we have to 
put restrictions on the ASM model to be checked in order to make it finite: all 
function ranges have to be restricted to a fixed finite set of values. To cope with 
a broader subset of the ASM language, we extend the basic work of [14], which 
introduced a simple transformation schema, to support the transformation of 
n-ary dynamic functions for n > 0. To ease the transition from infinite or large 
models to finite and feasible ones, we introduce a language feature for adjusting 
the function ranges in the declaration part of the system specification. Thus, 
such changes can be done locally and are not spread over the whole model. 

From a methodical point of view, model checking can support the early design 
phase: checking properties of the system behavior may yield counterexamples 
which help to “debug” the system specification. The simulator provided by the 
ASM Workbench can be fed with the counterexamples in order to illustrate 
the erroneous behavior. After locating and correcting the error that causes the 
counterexample, the transformation and model checking should be repeated. 
This debugging process gives a deeper insight into the model at hand. Errors 
become visible that can be easily over seen when carrying out mathematical 
proofs which are not mechanically checked, borderline cases become visible that 
are mostly not found when simulating isolated test cases. 

We are not claiming that model checking can replace, in general, mathemati- 
cal proofs (developed with or without the help of theorem provers), as the range 
of applicability of model checking techniques is restricted to the verification of 
finite instances of the problem at hand and is in most cases insufficient to prove 
correctness of a system or protocol in general. However, we argue that using tool 
support in the way we suggest helps to find errors with small additional effort. 

This paper is structured as follows: after introducing the main features of 
ASM (Sect. 2), we show how the transformation from ASM into the SMV lan- 
guage is performed (Sect. 3). Sect. 4 presents results from applying our approach 
to a case study, an ASM specification of the FLASH cache coherence protocol. 
Sect. 5 outlines related work. We conclude in Sect. 6 with an outlook to further 
possible improvements of our tool. 



2 Basic Notions of Abstract State Machines 

In this section we introduce some basic notions of ASM (see [7] for the complete 
definition). We first describe the underlying computational model and then the 
syntax and semantics of the subset of the ASM language needed in this paper. 



2.1 Computational Model 

Computations Abstract State Machines define a state-based computational 
model, where computations (runs) are finite or infinite sequences of states {Si}, 
obtained from a given initial state Sq by repeatedly executing transitions Sp. 
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States The states are algebras over a given signature S (or E-algebras for 
short). A signature E consists of a set of basic types and a set of function names, 
each function name / coming with a fixed arity n and type T\ . . .Tn T, where 
the Ti and T are basic types (written f : Ti ... Tn T , or simply / : T if n = 0). 
for each function name / : Ti . . . r„ — > T in A (the interpretation of the function 
name / in S'). Function names in E can be declared as: 

— static: static function names have the same (fixed) interpretation in each 
computation state; 

— dynamic: the interpretation of dynamic function names can be altered by 
transitions fired in a computation step (see below); 

— external: the interpretation of external function names is determined by the 
environment (thus, external functions may change during the computation 
as a result of environmental influences, but are not controlled by the system) . 

Any signature E must contain at least a basic type BOOL, static nullary function 
names (constants) true : BOOL, false : BOOL, the usual boolean operations (A, 
V, etc.), and the equality symbol =. We also assume that there is a (polymorphic) 
type SET{T) of finite sets with the usual set operations. When no ambiguity 
arises we omit explicit mention of the state S (e.g., we write T instead of 
for the carrier sets, and f instead of fs for static functions, as they never change 
during a run) . 

Locations If / : Ti . . . r„ — > T is a dynamic or external function name, we call 
a pair I = (/, x) with x S T( x . . . x a location (then, the type of Z is T and the 
value of Z in a state S is given by fs(x)). Note that, within a run, two states Si 
and Sj are equal iff the values of all locations in Si and Sj are equal (i.e., they 
coincide iff they coincide on all locations) . 

Transitions Transitions transform a state S into its successor state S" by 
changing the interpretation of some dynamic function names on a finite number 
of points (i.e., by updating the values of a finite number of locations) . 

More precisely, the transition transforming S into S' results from firing a 
finite update set A at S, where updates are of the form {(f,x),y), with (f,x) 
being the location to be updated and y the value. In the state S' resulting from 
firing A S the carrier sets are unchanged and, for each function name /: 

f„ ^ [y if iif,x),y) e A 
i ' (fs(a;) otherwise. 

Note that the above definition is only applicable if A does not contain conflicting 
updates, i.e., any updates {{f,x),y) and {{f,x),y') with y yf y' . 

The update set A-which depends on the state S~\s determined by evalu- 
ating in 5 a distinguished closed transition rule P, called the program. The 
program consists usually of a set (block) of rules, describing system behavior 
under different-usually mutually exclusive-conditions.^ 



^ See, for instance, the example in Sect. 4, containing a rule for each message type. 
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2.2 The ASM Language 

Terms Terms are defined as in first-order logic: (i) if / : T\ . . .Tn — > T is 
a function name in S, and ti are terms of type Ti (for i = then 

/(ti , . . . ,tn) is a term of type T (written t : T) (if n = 0 the parentheses are 
omitted, i.e. we write / instead of /()); (ii) a variable v (of a given type T) 
is a term. The meaning of a term t : T in a, state S and environment p is a 
value Sp{t) G T defined by:^ 

S (t) = f^siSpih),. . . ,Sp{tn)) ift = 

\p{v) iit = v. 

As opposed to first-order logic, there is no notion of formula: boolean terms are 
used instead. Finite quantifications of the form “{Q v In A ■. G)”, where Q is 
V or 3, ti : T, A : SET(T), and G : BOOL, are also valid boolean terms. ^ 

Transition rules While terms denote values, transition rules {rules for short) 
denote update sets, and are used to define the dynamic behavior of an ASM: the 
meaning of a rule i? in a state S and environment p is an update set As,p{R). 

ASM runs starting in a given initial state So are determined by the pro- 
gram P: each state 5i+i {i > 0) is obtained by firing the update set Ag. (P) 
at Si : 

AspiP) AsAP) „ ^s^_AP) „ 

Oo ^ ^ 02 ■ • ■ *■ On ■■ ■ 

Basic transition rules are the skip, update, bloek, and conditional rules. Addi- 
tional rules are the do-forall (a generalized block rule) and choose rules (for 
non-deterministic choice).^ 

R ::= skip | /(ti, . . . , tn) := t \ i?i . . . | if G then Rt else Rp 

I do forall v i.n A with G R' \ choose v ±n A with G R' 



The form “if G then i?” is a shortcut for “if G then R else skip”. Omitting 
“with G” in do-forall and choose rules corresponds to specifying “with true” . 
The semantics of transition rules is as follows: 



As, p( skip) 
As,p{f{ti, ...,tn):=t) 

^S.p( Rl ■ ■ ■ Rn) 
As,p{ if G then Rp else Rp ) 



{} 

{((/, (^p(G),...,5p(t„))),5p(t))} 

U”=i As.p(i?0 

f As,p{Rt ) if Sp{G) = true 
( As,p( Rp ) otherwise 



^ Environments-denoted by the letter p-are finite maps containing bindings which 
associate (free) variables to their corresponding values. We adopt the following no- 
tation: p[v x] is the environment obtained by modifying p to bind v to x, while p\v 
is the environment with the binding of variable v removed from p. For closed terms 
and rules, we omit explicit mention of p (e.g., if t is a closed term, S{t) = Suit)). 

® Also in the rest of this paper we use A for set-typed terms and G for boolean terms. 

^ The ASM Workbench support more rules, such as let and case rules with pattern 
matching: however, for reasons of space, we have to skip them here. 
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Z\s,p( do forall u in A with G R' ) = \Jxex ) 

where X = {x\x € Sp{A) A S'p[„^2:](G) = true}. 

Note that executing a block (or a do-forall) rule corresponds to simultaneous 
execution of its subrules® and may lead to conflicts. 

Choose rules are not directly supported by our transformation tool, but can 
always be replaced by external functions for arbitrary choice of a value (by a 
transformation similar to skolemization) . For example, let Ai be terms of type 
SET{Ti), i = 1,2,3, and fx ■ Ti, /z : 72 ^ T3 external functions with fx G Ai 
and fz{y) € A3 for each y & A^. Then the following two rules are equivalent: 

choose X in Ai 

do forall y in A 2 
choose z in A 3 

a{x,y,z) :=x + y + z 

Multi- Agent ASM Concurrent systems can be modelled in ASM by the no- 
tion of multi-agent ASM (called distributed ASM in [7]). The basic idea is that 
the system consists of more agents, identified with the elements of a finite set 
AGENT (which are actually sort of “agent identifiers”). Each agent a G AGENT 
executes its own program prog (a) and can identify itself by means of a special 
nullary function self : AGENT , which is interpreted by each agent a as a. 

As a semantics for multi-agent ASM we consider here a simple interleaving 
model, which allows us to model concurrent systems in the basic ASM formalism 
as described above. In particular, we consider self as an external function, whose 
interpretation selfg. determines the agent which fires at state Si. We assume 
that there is one program P, shared by all agents, possibly performing different 
actions for different agents, e.g.: 

if self = Oi then prog(ai) 
if self = Qn then prog(an) 

where {ai,...,a„j are the agents and prog{ai) is the rule to be executed by 
agent at, i.e., the “program” of a^. (The FLASH model presented in Sect. 4 is 
an example of this style of modelling, except that all agents execute exactly the 
same program, but on different data.) 

The ASM-SL Notation The ASM language, including all constructs above, 
is supported by the “ASM Workbench” tool environment [2], which provides 
syntax- and type-checking of ASM specifications as well as their simulation and 
debugging. The source language for the ASM Workbench, called ASM-SL, in- 
cludes some additional features which are necessary for practical modelling tasks: 
constructs for defining types, functions, and named transition rules (“macros”), 
as well as a set of predefined data types (booleans, integers, tuples, lists, finite 
sets, etc.): as the ASM-SL notation is quite close to usual mathematical notation, 
no further explanation of ASM-SL will be needed. 

® For example, a block rule a := b, b := a exchanges a and b. 



do forall y in A 2 

aifx,y,fz{y)) ■■= fx + y + fz{y) 



336 Giuseppe Del Castillo and Kirsten Winter 



3 Translating Abstract State Machines into SMV 

In this section, after a brief comparison of the ASM and SMV specification 
languages, we describe the transformation from ASM to SMV in two stages. First 
we recall the translation scheme introduced in [14], defined for a subset of ASM 
called ASMq in this paper (Sect. 3.1). Then we define a transformation technique 
to reduce any ASM specification to ASMq, such that the first translation scheme 
can then be applied (Sect. 3.2). 

ASM versus SMV While the computational model underlying both SMV and 
ASM is essentially the well-known model of transition systems, there are some 
significant differences: (1.) Abstract State Machines define, in general, systems 
with a possibly infinite number of states (as both the number of locations and the 
location ranges may be infinite); (2.) the way of specifying transitions in ASM 
and SMV is different: in SMV transitions are specified by next-expressions, 
which completely define the value which a state variable assumes in the next 
state, while updates of dynamic functions in ASM may be scattered troughout 
the program; (3.) the ASM notions of dynamic function and external function 
generalize the notion of state variable typical of basic transition systems (state 
variables correspond to nullary dynamic/external functions of ASM). 

The first issue is solved by introducing finiteness constraints, the second and 
third are addressed by the transformations of Sect. 3.1 and 3.2, respectively. 

Finiteness constraints In order to ensure that the ASM programs to be 
translated into SMV define finite-state systems, the user has to specify, for each 
dynamic or external function f : Ti .. .Tn T, a, finiteness constraint of the 
form f{xi, . . . ,Xn) € t[xi, . . . ,Xn], where t : SET(T) is a term denoting a fi- 
nite set, possibly depending on the arguments of / (see Fig. 1 for an example). 
For external functions, finiteness constraints correspond to environment assump- 
tions, expressed in the resulting SMV model by the range of the generated state 
variables; for dynamic functions, it must be checked that the constraints are not 
violated by the rules, resulting in the SMV code in appropriate proof obligations, 
which we call range conditions.^ 



3.1 The Basic Translation Scheme 

The translation scheme introduced in [14] can be applied to transform into SMV 
a subset ASMq of ASM, where: (i) only nullary dynamic and external functions 
are allowed; (ii) the only available data types are integers, booleans and enu- 
merated types; (Hi) the only defined static functions are those corresponding 
to predefined operations in SMV (boolean operations, -I-, -, etc.). 

As the semantic models for ASMq are essentially basic transition systems, 
the translation of ASM into SMV is very close: 



Note, however, that the range conditions can often be discarded by a simple static 
analysis of the rules, which prevents their expensive proof by model-checking. 
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— non-static functions (i.e., dynamic and external functions) are identified with 
locations and thus mapped one-to-one to SMV state variables; 

— values of the ASM data types are mapped one-to-one to SMV constants; 

— applications of static functions are translated to applications of the corre- 
sponding built-in operators of SMV. 



What remains to be done is to restructure the ASM program into a form where 
updates of the same location, together with their guards, are collected together. 
This is done in two steps. First, we transform an ASM program P into an equiv- 
alent ASM program P' consisting only of a block of guarded updates (i.e., rules 
of the form if G then f{t) := t) by means of a “flattening” transformation: 



[skip] = (empty block) 

[/(t) := t] = if true then /(t) := t 
[Ai ... = [All ••• IRnJ 



[At] 

[Af] 



if G\ then Ay 



if G A Gy then Ay 



if Gy then A? 

, , ^ [if G then Ay else Ay] = 

if G\ then A). " 



if G A Gy then Ay 
if -iG A Gy then Ay 



if Gy then Ay 



if ^G A G^ then 



Second, we collect all guarded updates of the same location, thus obtaining, 
for each location loc occurring on the left-hand side of an update in P', a pair 
{loc, {(Gi, ti), . . . , (G„, tn)}) which maps loc to a set of pairs (guard, right-hand 
side). Such a pair is translated into the following SMV assignment:^ 

ASSIGN next(C[Zoc]) : = 

case C|Gi| : C[ti] ; ... C[G„] : C|tn| ; 1 : C[Zoc] esac; 

where C[.| denotes here the ASM — s- SMV compiling function for terms, which 
is straightforward for ASMq. For each location I of a dynamic function /, in 
addition to the next assignment above, the transformation also generates the 
location’s initialization (an init assignment in SMV) as well as two proof obli- 
gations, a range condition (see discussion of finiteness constraints above) and a 
no-conflict condition^ which ensures that no conflicts arise on this location. In 
fact, due to the semantics of case in SMV, the translation scheme is correct only 
if for all i,j with i ^ j, S \= ~^{Gi A Gj) V {ti = tj) in any reachable state S: 
if, in some state S, this condition is not satisfied, the ASM transition produces 
a conflict (i.e., an error), while the corresponding SMV transition simply picks 
one of the updates (the first one in the case whose guard is satisfied).® 



3.2 The Extended Translation Scheme 

In this section we show how to reduce an arbitrary (finite-state) ASM to ASMq. 
This transformation allows to deal with the complete ASM language as in [7], 

^ Note that we have to specify the default case explicitly (if none of the guards is true) 
which is given implicitly in ASM rules (see ASM semantics above). 

® Like range conditions, no-conflict conditions can be often discarded statically. 
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with the exception of import rules (rules which allow the dynamic creation of 
elements at run-time) and choose rules. (However, one can deal with choose as 
explained in Sect. 2.2.) Arbitrary data types and operations (in particular, lists, 
finite sets, finite maps and user-definable freely generated types, as provided by 
ASM-SL) can be used without any restriction. Finite quantifications are also 
supported. 

The main problem here, as opposed to ASMq, is that in general we do not 
know which location is updated by an update rule /(ti, . . . , tn) ■= t (if n > 0): 
the updated location may differ from state to state if some U contains non-static 
function names. However, if all terms ti contain only static function names, they 
can be evaluated statically to values xt, and the term /(ti, . . . , t„) to the location 
I = (/, x). Thus, the basic idea of the transformation is to iteratively unfold and 
simplify rules until all terms can be reduced to values or locations. 

To formally define the transformation, we extend the syntactic category of 
terms to “partially evaluated terms” (simply called “terms” in the sequel) by 
adding values and locations: 

t ::= /(ti,...,t„) I V I (Qv±nA:G) \ x \ I 

(We adopt the convention that x stands for a value and I for a location). 

Terms can be simplified by means of the transformation |.|p defined in Ta- 
ble 1, which is then extended to rules in a canonical way. Note that, whenever p 
contains bindings for all free variables occurring in t: (i) if t is a, static term, then 
p]]p is a value x (coinciding with Sp{t) in every state S); (ii) if t = /(ti, . . . , tn) 
is a term where f is a dynamic or external function name and all the subterms ti 
are static (we call such a term a locational term), then |t]p is a location 1.® 

The rule-unfolding transformation £, which operates on closed rules such as 
the program P, is formally defined in Table 2. It works as follows: 

— if the rule R consists of a block of update rules of the form location := value, 
it terminates and yields R as result (there is nothing left to unfold); 

— otherwise, it looks for the first location I occurring in R (but not as left-hand 
side of some update rule) and unfolds R according to the possible values^° 
of 1. In turn, the unfolding has to be applied to the subrules |i?[^/xi]]] ob- 
tained by substituting the values Xi for I in R and simplifying. 

Applying £ to the (simplified) ASM program [[PI0 yields a program P' = 
£(|P|0) which is essentially an ASMq program (formally, the locations have still 
to be replaced by nullary dynamic or external function names and the values by 
nullary static function names, i.e. by constants). 

® A simple consequence of this fact is that every closed static term simplifies to a value 
and every closed locational term to a location. 

The finite range of location I = (/, ®) is derived from the finiteness constraint for /. 
The unfolding transformation often results in very large decision trees (case- 
structures in SMV) : however, this does not have a negative influence on the efficiency 
of verification with SMV, as the verification costs depend on the size of the BDDs 
representing the transition relation and not on the size of the SMV source code (and 
BDDs, for a given variable ordering, are a canonical representation). 



Model Checking Support for the ASM High-Level Language 339 




Term Simplification 



[xIp = X 



X = p{v) if V € dom(p) 

V otherwise 



pi]p = Xi for each i G {1, . . . ,n} ^ 

Ij-., _ j X = t{xi, . . . ,x„) if / static function name 

ii • • • 1 n)ip I ^ ^ x„)) if / dynamic/external function name 



pilp = I or pi|p = f'{t ) for some i G {1, . . . , n} ^ 

. . . ,tn)lp = /(Pllp,- • • , PnEp) 

{ |f^I]p[u^3;i] [If^Ep[i;^3:n] 

if |A]]p = x = {xi, ...,Xn} (i.e., if |[A|p is a value) 

(Q u in [Alp : [Gl(p\„)) 
otherwise. 

(where op = A if Q = forall, op = V if Q = exists). 

Rule Simplification 

[skipip = skip 

pn := tfllp = pnlp := PhIp 

[Ri ... R„1 p = [Rilp ... [R„1 p 



r [RtEp if[Glp=true 

[if G then Rt else 7 ?f1p = s [Rf]p if [GJp = false 

t if [GJp then [RtIp else [RfIp otherwise. 

[do forall u in A with G i?^|p = 

{ [if G then i?'lp[„H^;i,i] ... [if G then i?']p[„^ 2 .„] 

if [A]p = X = {* 1 , . . . , Xn} (i.e., if [A]p is a value) 
do forall v in [A|p with [G](p\„) [R'l(p\„) 
otherwise. 



Table 2. Rule Unfolding 

Rule Unfolding 

If R has the form h := xi . . . In '■= x„, then E{R) = R. 

Otherwise: 

E(R) = i± I = x\ then f([7?[l/a;i]|0) 

else if I = X 2 then £{\R[l / xi\\(i)) 

else if I = Xn then £{\R\l/xn]\it) 

where I is the first location occurring in R (but not as Ihs of an update rule) 
and {xi, . . . , Xn} is the range of location 1. 
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Fig. 1 illustrates graphically the transformation technique (for simplicity, we 
consider a rule without variables, such that we can omit mentioning environ- 
ments). The root of the tree-enclosed in the dashed box-is the (simplified) ASM 
program [P] to be transformed. The successors of each node in the tree are ob- 
tained as result of an unfolding step (under the given finiteness constraints) : for 
instance, the successors of the root node are the rules [[P] [a/l]], [[[P] [a/2]|, 
and [[[P] [a/3]], respectively. Locations are emphasized by enclosing them in 
boxes: note that, at the leaves, locations occur only as left-hand side of updates, 
thus they cause no further unfolding. The dashed box on the right contains 
the ASMo program produced by the transformation: note that the locations ac- 
tually affected by the ASM program-which are revealed by the unfolding-are 
mapped to nullary functions (“state variables”), whose ranges are derived from 
the finiteness constraints (see box at the top right corner). 



Finiteness constraints 




a e {1,2,3} 


ASM 


/We (x,x+l ) 


; if [^ < 2 I 


g(x)e { ) 


then g(f(m)) := S] 1 



Locations — » State variables 


a — » a : { 1, 2, 3 } 


(g.(l)) 


—> 


gl-- 


[ ) 


^ // : 1 1,2) 


(g.(2)) 




g2- 


[ ) 


(f,(2» f2: 12, 3] 


(g.(3» 




g2- 


( ) 



g(\K<M}-=> g(\jun)-=2 

/ \ / \ 

(f.(l» = I (f.(I» = 2 (f,(2» = 2 (f,(2)) = 3 

/ \ / \ 

[gM)\-=l [^-=2 



skip 






ASMg 

if a = 1 

then if fl = l then 
if fl=2 then 
else if a = 2 
then If J2 = 2 then 
if f2 = 3 then 
else if a = 3 then 



gl ■.= ! 
g2 -.= 1 

g2 :=2 

g3 :=2 
skip 



Fig. 1. Rule Transformation Example 



4 Case Study: The FLASH Cache Coherence Protocol 

As an example for our model checking approach we chose a formalization of the 
FLASH protocol [9] with ASM. Our model is based on the work of Durand [4]. 
In Sect. 4.1, after a short introduction to FLASH, we describe an ASM model 
derived from [4] and motivate our refinements. Then we sketch the debugging 
process supported by the transformation and checking with SMV (in Sect. 4.2). 

4.1 FLASH Cache Coherence Protocol 

The Stanford FLASH multiprocessor integrates support for cache coherent 
shared memory for a large number of interconnected processing nodes. Each 
line-sized block of the distributed memory is associated with a home node con- 
taining the part of the physical memory where that line resides. Every read or 
write miss concerning a remote memory line triggers a line request to its home 
node that in turn initiates the corresponding part of the protocol. The request 
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may ask for shared or exclusive access depending on whether reading or writing 
access is wanted. 

The ASM description of the protocol is based on agents. A set of transition 
rules describes the behavior of a single agent. The behavior is determined by the 
currently processed message type - a notion that yields the clear model structure 
that is sketched in Fig. 2. 

Message Structure. A message is modeled as a quintuple consisting of 
the type of the message, the addressed agent, sender agent, agent initiating the 
request and requested line^^. Message types related to shared access are: 

get : requesting a line from its home 

put : granting a line to the requester (source of the request) 

f wdget : forwarding the request to an exclusive owner of the line 

swb : requesting a write-back of an owned line that is to be shared 

nack , nackc : negatively acknowledging the request or forwarded request re- 

spectively, if it cannot be performed now. 

In analogy, message types related to exclusive access are: 
getx, putx, fwdgetx, and also 

inv : requesting a current sharer of the line to invalidate its local copy 

invAck : acknowledging the invalidation of the line 

fwdAck: owner’s granting according to a forwarded shared request. 

Additionally, for releasing a shared or exclusive copy from its cache an agent 
sends a write_back (wb) and a replace message (rpl) to home, respectively. A read 
or write miss of a line, or the end of accessing, is simulated with the help of an 
oracle function which non-deterministically triggers an agent to send get/getx 
or rpl/wb messages. 

State Functions. Besides the message type, the agent’s behavior depends 
on several local state variables: curPhase(line) (phase of the current request), 
State(line) (state of the local line copy in use), and pending (line) (flag for cur- 
rently processed request). Owner(line) and the set of Sharers of a line are also 
taken into account. 

Adjustable Parameters. The transition rules are parameterized by self, 
the agent that is currently active (this is implicit in Fig. 2), and the requested 
line. The domains of these parameters. Agents and Lines, and their extent are 
easily adjustable in the declaration part of the specification. 

Necessary Refinements. Sending a message is given as a macro definition. 
In the abstract model of [4] SendMsg adds a message to a (possibly infinite) set 
of messages in transit. The strategy for receiving a message from this set is not 
specified. For the proof it is just assumed that the messages are received in the 
right order. In order to keep the model finite and to formalize the assumption on 
the model behavior we have to refine the model. We replace the set of messages 
in transit by a finite queue for each agent, and we extend the overall behavior 
by means of a sub-step for synchronization. In the synchronization step the 
messages are passed through to the addressed agent in the proper order. 



12 



In our adaptation of the model the parts related to data are discarded. 
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if MessType — get 



then if pending{l) then SendMsg(nack., source, self, source, 1) 
else if Owneril) 7 ^ undef 

then SendMsg{fwdget, Owneril), self, source, 1) 
pendingil) : = true 
else SendMsgiput, source, self, source, 1) 
Sharer (I, source) := true 



then . . . 



fwdget 


if MessType — 


put 


if MessType = 


swb 



if MessType — \ nack 



if MessType = \ nackc 



then curPhase{l) ; = ready 



then pendingil) := false 



if MessType = getx 



then if pendingil) 

then SendMsginacli, source, self, source, 1) 
else if Owneril) 7 ^ undef 

then S'endMs 5 (fwdgetx, Owneril), self, source, 1) 
pendingil) : = true 
else if 3m : Shareril, u) 

then Vu : Shareril, u) SendMsgiinv , u, self, source, 1) 
pendingil) : = true 

else SendMsgiput-x., source, self, source, 1) 

Owneril) : = source 



if MessType = fwdgetx 
then . . . 



if MessType = 

then . . . 



fwdAck 



if MessType — 



then SendMsgiiuwA.c]c, home, self, source, 1) 
if Stateil) = shared 

then Stateil) : = invalid 
else if curPhaseil) = wait 

then curPhaseil) : = invalidPhase 



if MessType — 



invAck 



then Shareril. MessSender) := false 

if Va : Agents \ a 7 ^ MessSender A Shareril, a) = false 
then SendMsgiputx, source, self, source, 1) 
pendingil) ;= false 



if MessType = 

then . . . 



putx 


if MessType — 


rpl 


if MessType = 


wb 



Fig. 2. Agent behavior modeled by ASM transition rules 







Model Checking Support for the ASM High-Level Language 343 



In an ASM model, introducing a sub-step is structure preserving: in addition 
to the ASM for message computation (explained above) we specify an ASM 
for the message passing through. An overall ASM invokes both “sub-ASMs” in 
turn. Taking this, we benefit from the clear and understandable structure of 
the abstract model. The entire refined ASM-model is available on the web at 
http : //www . f irst . gmd . de/~kirsten/publications/f lash_parami . asm. 



4.2 Model Checking the Transformed System Specification 

We take model checking of the transformed ASM model as an evolutionary pro- 
cess of debugging: we edit the ASM model, transform it automatically into an 
SMV model, run SMV to check the properties under investigation, investigate 
the resulting counterexample (if any) within the ASM model, and debug the 
ASM model. Since there are no restrictions on the behavior of the environment 
(producing requests on a line), we do not suffer from “wrong” counterexamples 
that are not suitable for debugging the ordinary system behavior. (We call coun- 
terexamples wrong, if they are caused by non-reasonable environment behavior 
that should be excluded. They obstruct the debugging process, since only one 
counterexample will be produced.) 

As the debugging process is more efficient if the model checking terminates 
in a reasonable span of time, we keep our model as small as possible. We find 
that, even when the model is restricted to few agents and lines, we detect errors 
in the abstract model as well as in our refinement. In the following we describe 
two of them as examples. We check the model for safety and liveness, i.e.: 

— No two agents have exclusive access on the same line simultaneously. 

— Each request will eventually be acknowledged. 

— Whenever an agent gets shared access, home will note it as a sharer. 

We formalize these requirements in CTL, e.g.^^: 

Ai^j[AG ( ! (State(a(i) ,l)=exclusive & State(a(j) ,l)=exclusive))] 

AJAG (curPhase(a(i) ,1) = wait -> AF (curPhase (a(i) , 1) = ready))] 
AJAG (State(a(j) ,l)=shared -> AX (Sharer(l,a(i)) = true))] 

Our first counterexample shows simultaneous exclusive access (for reasons of 
space we have to omit the listing here). The error that caused the counterexample 
can also be found in the abstract ASM model of [4]: 

Whenever a putx-message is sent to grant exclusive access the addressed 
requester has to be noted as owner of the line. This is specified in the 
getx-rule but it is missing in the invAck-rule that might also cause a 
putx-message to be send (see also Fig. 2). The protocol is unsafe since 
simultaneous exclusive access may occur, and written data may be lost. 



13 



Though the third specification is rather weak, it yields helpful counterexamples. 
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The following counterexamples are dedicated to the problem of racing (i.e., con- 
flicts) on the finite message queue. Although our data space is limited to a very 
short queue, we can derive more general remarks, e.g.: 

Each sharer of a requested line has to process the rule for invalidation 
(inv-rule). It sends an invAck-message to home for acknowledging the in- 
validation. When receiving an invAck-message, home deletes the sender 
from the list of sharers. If home is sharer too,^"^ a deadlock may occur if 
the number of sharers is greater or equal than the length of the message 
queue: home may fail to complete with the inv-rule when the queue is 
full and sending a message is not possible (since every other sharer may 
have sent before); home stays busy and can not process the incoming 
invAck-rule to clear the queue. In general, we found out that the mes- 
sage queue must be larger or equal than the number of agents since in 
the worst case each agent is a sharer and will send simultaneously an 
invAck-message to the home node. 

The examples show that helpful borderline cases can be detected more easily 
by a model checker than by pure simulation. The computational effort for the 
automated transformation of our models ranges from three to five seconds. The 
size of the resulting SMV models is given below. The variable ordering is 
determined by the automatic reordering facility that is given by the SMV. 



resources used: 


2 agents, 1 line 


3 agents, 1 line 


2 agents, 2 lines 


user time/system time: 


4.69 s/0.13 s 


5687.52 s/0.6 s 


17263.2 s/0.86 s 


BDD nodes allocated: 


70587 


1612740 


2975127 


Bytes allocated: 


4849664 


37748736 


54657024 


BDD nodes repr. transition relation: 


19261 -b 78 


288986 -b 82 


78365 -b 96 



Although checking our model of the FLASH protocol is only feasible for a small 
number of agents and lines, the results show that the counterexamples yield 
extremely helpful scenarios for locating errors. 



5 Related Work 

Extending tool environments for high-level specification languages with an inter- 
face to a model checker is an upcoming topic. One can find approaches that are 
quite similar to ours but work on a different language: [3] suggests a transforma- 
tion from Statecharts into SMV, in [10] Controller Specification (CSL) models 
are transformed and model checked by SVE, [12] equips the multi-language en- 
vironment Synchrgnie with an interface to the VIS model checker, etc. 

Closer to our approach from the language point of view, [13] also investigates 
automatic verification of ASM. Spielmann represents an ASM model indepen- 
dently of its possible input by means of a logic for computation graphs (called 

This is possible if we allow intra-node communication. 

The experiments were carried out on an UltraSPARC-II station with 296MHz and 

2048 Mb memory, the operating system is Solaris 2.6. 
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CGL*). The resulting formula is combined with a CTL*-like formula which spec- 
ifies properties and checked by means of deciding its finite validity. This approach 
addresses the problem of checking systems with infinitely many inputs, but it is 
only applicable to ASM with only 0-ary dynamic functions (i.e. ASMg programs) 
and relational input, which is the second result of [13]. 

6 Conclusions 

We presented an interface from the ASM Workbench to SMV, based on a trans- 
formation from ASM to the SMV language extending the one defined in [14] by 
the treatment of dynamic functions of arity n > 0. This is essential, as most ASM 
specifications benefit from the abundant use of parametric dynamic functions. 

The practicability of our approach is demonstrated by a non-trivial case 
study: the ASM model of the FLASH protocol. By example we show that errors 
can be found in the ASM model that will hardly be detected by pure mathe- 
matical proofs, and deduce more general constraints for the model at hand from 
the counterexamples. 

We support the exploitation of the model checking facility by means of intro- 
ducing finiteness constraints into the ASM specification language for easy control 
of the function ranges in order to restrict the state space of the model. Addition- 
ally, the developer benefits from the automatically generated proof obligations 
to be checked by SMV: the no-conflict conditions and the range conditions. 

Some improvements of our tool, which are still to be implemented in order 
to make the transition between ASM and SMV smoother and thus ease the 
validation process, include the automatic translation of the counterexamples 
into a form which can be immediately read and simulated by the Workbench 
and the embedding of CTL operators into the ASM-SL language. 
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Abstract. Markov chains are widely used in the context of performance 
and reliability evaluation of systems of various nature. Model checking 
of such chains with respect to a given (branching) temporal logic for- 
mula has been proposed for both the discrete [17,6] and the continuous 
time setting [4,8]. In this paper, we describe a prototype model checker 
for discrete and continuous-time Markov chains, the Erlangen- Twente 
Markov Chain Checker (E h MC^), where properties are expressed in 
appropriate extensions of CTL. We illustrate the general benefits of this 
approach and discuss the structure of the tool. Furthermore we report on 
first successful applications of the tool to non-trivial examples, highlight- 
ing lessons learned during development and application of E h MC^ . 



1 Introduction 

Markov chains are widely used as simple yet adequate models iu diverse areas, 
raugiug from mathematics aud computer science to other disciplines such as 
operations research, industrial engineering, biology and demographics. Markov 
chains can be used to estimate performance characteristics of various nature, for 
instance to quantify throughput of manufacturing systems, locate bottlenecks in 
communication systems, or to estimate reliability in aerospace systems. 

Model checking is a very successful technique to establish the correctness 
of systems from similar application domains, usually described in terms of a 
non-deterministic finite-state model. If non-determinism is replaced by random- 
ized, i.e. probabilistic decisions, the resulting model boils down to a finite- 
state discrete-time Markov chain (DTMC). For these models, qualitative and 
quantitative model checking algorithms have been investigated extensively, see 
e.g. [3,5,6,10,13,17,29]. In a qualitative setting it is checked whether a property 
holds with probability 0 or 1; in a quantitative setting it is verified whether the 
probability for a certain property meets a given lower- or upper-bound. 

Markov chains are memoryless. In the discrete-time setting this is reflected 
by the fact that probabilistic decisions do not depend on the outcome of deci- 
sions taken earlier, only the state currently occupied is decisive to completely 

* supported by the German Research Council DFG under HE 1408/6-1. 



S. Graf and M. Schwartzbach (Eds.): TACAS/ETAPS 2000, LNCS 1785, pp. 347—362, 2000. 
© Springer-Verlag Berlin Heidelberg 2000 



348 Holger Hermanns et al. 



determine the probability of next transitions. For continuous-time Markov chains 
(CTMCs), where time ranges over (positive) reals (instead of discrete subsets 
thereof) the memoryless property further implies that probabilities of taking 
next transitions do not depend on the amount of time spent in the current state. 
The vast majority of applications of Markov chain modelling involves CTMCs, as 
opposed to DTMCs.^ In particular, CTMCs are the underlying semantic model 
of major high-level performance modelling formalisms such as stochastic Petri 
nets [1], stochastic automata networks [26], stochastic process algebras [24,21], 
Markovian queueing networks [12], and various extensions thereof. 

Model checking of CTMCs has been discussed in [8], introducing a (branch- 
ing) temporal logic called continuous-time stochastic logic (CSL) to express 
properties over CTMCs. This logic is an extension of the (equally named) logic 
by Aziz et al. [4] with an operator to reason about steady-state probabilities: 
e.g. the formula asserts that the steady-state probability for being in a 

<?-state is at least p, for p G [0,1]. Apart from the usual quantifiers like next 
and until, a time-bounded until , for t a non-negative real, is incorporated, 
for which standard derivatives, such as a time-bounded eventually can 

be defined. The usual path quantifiers V and 3 are replaced by the probabilis- 
tic operator 'P X]p ( • ) for comparison operator cxi and p G [0,1]. For instance, 
7^<i0-9(O^^error) asserts that the probability for a system error within 4 time- 
units is less than 10“®. Such properties are out of the scope of what can be 
computed with standard Markov chain analysis algorithms, yet they are highly 
interesting to study. 

In this paper we describe the Erlang en-Twente Markov Chain Checker 
(E h MC^), to our knowledge the first implementation of a model checker for 
CTMCs. It uses numerical methods to model check CSL-formulas, based on [8]. 
Apart from standard graph algorithms, model checking CSL involves matrix- 
vector multiplications (for next-formulas), solutions of linear systems of equa- 
tions (for until- and steady-state formulas) , and solutions of systems of Volterra 
integral equations (for time-bounded until). Linear systems of equations are 
iteratively solved by standard numerical methods [27]. Systems of integral equa- 
tions are iteratively solved by piecewise integration after discretization. As a 
side result, E h MC^ is also capable to model check DTMCs against properties 
expressed in PCTL [17]. This is not surprising, taking into account that the 
algorithms needed for CSL are a superset of what is needed to check PCTL. 
The tool has been implemented in Java (version 1.2), and uses sparse matrix 
representations. The paper illustrates how E h MC^ can be linked (among oth- 
ers) to (generalized) stochastic Petri nets (GSPN) and to Markovian queueing 
networks by reporting on the model checking of a GSPN-model of a cyclic server 
system and of a tandem queueing network. 

Other model checkers for probabilistic systems are the DTMC-model checkers 
ProbVerus [18] and TPWB (the Timing and Probability Work-Bench) [15], 



^ DTMCs are mostly applied in strictly synchronous scenarios, while CTMCs have 
shown to fit well to (interleaving) asynchronous scenarios. 
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and the recent symbolic model checker for (discrete-time) Markov decision pro- 
cesses [2]. 

The paper is organized as follows. Section 2 briefly introduces CTMCs and 
CSL. Section 3 discusses the tool architecture together with the model check- 
ing algorithm and some implementation details. Section 4 reports on practical 
experiences with two case studies and Section 5 concludes the paper. 

2 Continuous-Time Markov Chains and CSL 

This section reviews continuous-time Markov chains [27] and CSL [8]. 

Continuous-time Markov chains. Let AP be a fixed, finite set of atomic 
propositions. A (labelled) continuous-time Markov chain (CTMC for short) is a 
tuple M = (S', R, L) where S is a finite set of states, R : S x S ^ the rate 
matrix, and L : S ^ 2^^ the labelling function which assigns to each state s € S 
the set L(s) of atomic propositions a € AP that are valid in s. 

Intuitively, R(s, s') specifies that the probability of moving from state s to s' 
within t time-units (for positive f) is 1 — an exponential distribu- 

tion with rate R(s, s'). If R(s, s') > 0 for more than one state s', a competi- 
tion between the transitions exists, known as the race condition. Let E(s) = 
Z^s'gS I^('Sj'S'), the total rate at which any transition emanating from state s is 
taken. This rate is the reciprocal of the mean sojourn time in s. More precisely, 
E(s) specifies that the probability of leaving s within t time-units (for positive t) 
is 1 — due to the fact that the minimum of exponential distributions 

(competing in a race) is again exponentially distributed, and characterized by 
the sum of their rates. Consequently, the probability of moving from state s 
to s' by a single transition, denoted P(s,s'), is determined by the probability 
that the delay of going from s to s' finishes before the delays of other outgoing 
edges from s; formally, P(s, s') = R(s, s')/E(s) (except if s is an absorbing state, 
i.e. if E(s) = 0; in this case we define P(s, s') = 0). Remark that the matrix P 
describes an embedded DTMC. 

A path cr is a finite or infinite sequence sq, toj si, fi, S 2 , ^ 2 , • ■ ■ with for i € 
IN, Si G S and U G IR>o such that R(si,Si+i) > 0, if cr is infinite. For infinite 
path a, t G IR^o £md i the smallest index with t Gi kt a@t = Si, the 

state of a at time t. If a is finite and ends in sj, we require that s; is absorbing, 
and R(si,Si+i) > 0 for all i < 1. For finite a, a@t = si for t > 
other t it is defined as above. Let Path(s) be the set of paths starting in s. 

Continuous stochastic logic. CSL is a branching-time, CTL-like temporal 
logic where the state-formulas are interpreted over states of a CTMC. 

Definition 1. For a G AP, p G [0,1] and ixi G the state- 



formulas o/CSL are defined by the grammar 




<P ::= a 


<P AF 




V^p{X<P) 







The other boolean connectives are derived in the usual way. The probabilis- 
tic operator Pmp(-) replaces the usual CTL path quantifiers 3 and V that can 
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be re-invented - up to fairness [9] - as the extremal probabilities 7^>o(-) and 
Formula Vt^p{X<P) ^ ^ 2 ), respectively) asserts that the proba- 

bility measure of the paths satisfying X(l> {4>i lA <^ 2 ) satisfies ixi p. The meaning 
of X (“next step”) and lA (“until”) is standard. The temporal operator lA^^ 
is the real-time variant oi IA\ lA^* <^2 asserts that lA <^2 will be satisfied 
in the time interval [0,t]; i.e. there is some a; S [0,t] such that continuously 
holds during the interval [0, and <^2 becomes true at time instant x. The state 
formula asserts that the steady-state probability for a ^-state satisfies 

txip. Temporal operators like O, □ and their real-time variants or can 
be derived, e.g. 7 ^mp(0^*^) = Vc^pitruelA^* ^P) and V^p{0(p) = V^i-p^O ^'P). 

Semantics of CSL. Let A4 = (S', R, L) with proposition labels in AP. The 
semantics for atomic propositions, negation, and conjunction is standard [11]. 
Let Sat{P) = {sSS|s^^}. The steady-state operator is defined by: 

s\=S^p{P) iff 7TSat(,p)(s) ixip 

where 715 /( 5 ) denotes the steady-state probability for S' C S when starting in s, 
77S'(s) = lim Pr{ a G Path(s) | a@t G S' }. 

t—*oo 

This limit exists for finite S [27]. Obviously, 715 /( 5 ) = X^s'gS' where we 
write 7Ts/(5) instead of 7 T{s/}( 5). We let 7T0(5) = 0. 

For path- formula ip of the form XP, PilA P 2 , or Pi lA^* P 2 we have: 

s [= Vtxipip) iff Prob{s,(f) 1 x 1 p, where Prob{s,(p) = Pr{ a G Path(s) | cr ^ p} 

i.e., Prob{s, ip) denotes the probability measure of all paths a G Path(s) sat- 
isfying ip The fact that, for each state 5, the set { cr G Path(s) | cr [= p } is 
measurable, follows by easy verification given the Borel space construction on 
paths through CTMCs in [8]. The semantics of next and until- formulas is stan- 
dard [11] and is omitted here. For time-bounded until we have: 

iff 3a; G [0, f]. (cr@a; [= <?2 A Vp G [0, x[. cr@p ^ ^ 1 ) . 

3 The Model Checker E h MC^ 

E h MC^ is a prototype tool supporting the verification of CSL-properties over 
CTMCs. It is a global model checker, i.e. it checks the validity of a formula for all 
states in the model. E h MC^ has been developed as a model checker that can 
easily be linked to a wide range of existing high-level modelling tools based on, for 
instance, stochastic process algebras, stochastic Petri nets, or queueing networks. 
A whole variety of such tools exists [20], most of them using dedicated formats 
to store the rate matrix R that is obtained from the high-level specification. 
The matrix R, together with the proposition-labelling function L, constitutes 
the interface between the high-level formalism at hand and the model checker 
E h MC^. Currently, E h accepts CTMCs represented in the tr a- format 
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as generated by the stochastic process algebra tool TIPPtool [22], but the tool 
is designed in such a way that it enables a filter plug-in functionality to bridge 
to various other input formats. This is realized via Java’s dynamic class loading 
capability. 



3.1 The Model Checking Algorithm 

Once the matrix R and the labelling L of a CTMC A4 have been initialised, 
the model checking algorithm implemented in E h MC^ essentially proceeds in 
the same way as for model checking CTL [11]. For a given formula 'P it recur- 
sively computes the sets of states Sat{.) satisfying the sub-formulas of P, and 
constructs the set Sat{P) from them. The verification of probabilistic and steady- 
state properties relies on the constructive characterizations for Prob{s, ip) and 
7Ts/(s) as established in [8]. 

Steady-state properties. For calculating Sp<^p{P) the tool follows a two-phase 
approach: first, the bottom strongly connected components (BSCC) of Ai are 
determined by a standard graph algorithm [28]. Then, the steady-state prob- 
ability distribution is calculated for each of the BSCC. Each step requires the 
solution of a linear system of equations in the size of the BSCC. More precisely, 
let G be the underlying directed graph of M where vertices represent states and 
where there is an edge from s to s' iff R (s, s') > 0. Sub-graph S is a BSCC of G 
if it is a strongly connected component such that for any s G B, Reach(s) C B. 
We have tTs'{s) = 0 iff s' does not occur in any BSCC reachable from s. Let B be 
a BSCC of G with Reach{s)nB yf 0, or equivalently, B C Reach(s), and assume 
that as is an atomic proposition such that as G L{s) iS s G B. Then Oob is a 
path-formula in CSL and Pro6(s, Oas) is the probability of reaching B from s 
at some time t. For s' G B, 7Ts/(s) is given by 7 Ts/(s) = Prob{s,OaB) ■ t^b{s') 
where 7 Tb(s') =1 if B = {s'}, and otherwise ttb satisfies the linear system of 
equations^ 

^ ^b(s) • R(s, s') = ttb{s') ■ ^ R( s', s) such that ^7 Tb(s) = 1. (1) 

sGB sGB seB 

s^s' s^s' 



Linear systems of equations can be solved either directly (e.g. Gaussian elimina- 
tion or LU-decomposition) or by iterative methods such as the power method, 
Jacobi iteration, Gaufi-Seidel iteration and successive over-relaxation [27]. Iter- 
ative methods compute approximations to the exact result up to a prespecified 
precision e. Although (except for the power method) convergence of the iterative 
methods is not guaranteed, this problem only appears for pathological cases in 
practice. The major advantage of these methods is that the involved matrices do 
not change during the computation (i.e. fill-in is avoided), and hence the buildup 
of rounding errors is nonexistent [19,27]. In addition, direct methods are known 

^ In [8] the above linear system of equations is defined in a slightly different way, by 
characterizing the steady-state probabilities in terms of the embedded DTMC. 
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to be only practical for state spaces of up to a few hundred states, while itera- 
tive methods have successfully been applied for much larger systems (up to 10^ 
states) [14]. For these reasons, E h supports all of the above mentioned 

iterative methods to solve (1). 

Probabilistic path-formulas. Calculating the probabilities Prob{s, (p) pro- 
ceeds as in the discrete-time case [13,17,5], except for the time-bounded until 
that is particular to the continuous-time case. More precisely: 

Next: Prob(s, X<P) is obtained by multiplying the transition probability matrix 
P with the (boolean) vector 14, = (i,jj(s))sgs characterizing Sat{<P), i.e. J<p(s) = 1 
if s ^ and 0 otherwise. 

Until: Prob{s, 7/ ^2) is obtained by solving a linear system of equations of the 
form X = P • X -I- i< 2>2 where P(s, s') = P(s, s') if s ^ A ^^2 and 0 other- 
wise. Prob{s,^iU <1>2) is the least solution of this set of equations. E h 
computes the least solution by one of the standard methods mentioned above 
for the steady-state operator. 

Time-bounded until: to compute the time-bounded until operator, we use the 
following characterization: 

Theorem 1. [8] The function S x [Ojlj; (s,t) Prob{s,<PiU^^ <1>2) 

is the least fixed point of the hiqher-order operator f2 : (S x lR>n [0,1]) — > 
{S X m^o ^ [0,1]) where^ 

( 1 if s\= ^2 

C(F)(s,t)=< R'(s:s') ■ /o rfa; j/s^^iA^^2 

[ 0 otherwise. 

This result suggests the following iterative method to approximate 
Prob{s,^iU^* <T2). let Fq{s,t) = 0 for all s, t and Fk+i = C(F’fc). Then, 
lim Fk{s,t) = Prob{s,T>iU^* T>2). 

k — >00 

Each step in the iteration amounts to solve an integral of the following form: 

Fk+i{s,t)= R(s, s') • • Efc(s',t-a;) dx, 
s’es 0 

if s \= <PiA ^T>2 ■ In [8] , we proposed to solve these integrals numerically based on 
quadrature formulas with, say, iV -|- 1 equally spaced interpolation points Xm = 
m ■ (0 ^ m ^ N) such as trapezoidal, Simpson, or Romberg integration 

schemes. For the trapezoidal method, for instance, this amounts to approximate 

m 

Fk+i{s,Xm) « R(s,s') • X) • Efc(s',Xm - a:j) 

s'GS j=o 

where for fixed m, ag = am = 5^ and aj = lor 0 < j < m. However, 
practical experiments with E h MC^ revealed that these schemes may result in 
inaccurate results by overestimating the impact of the ‘leftmost’ intervals. We 
therefore take a different route by using piecewise integration, and approximat- 
ing 

® The underlying partial order on S x IR^o — > [0, 1] is defined for Fi, F2 '■ S x IR^o — > 
[0, 1] by Fi ^ F2 iff Fi{s,t) ^ F2(s,t) for all s,t. 
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Fk+l{s,Xm) « I] R(s, dx ■ Fk{s\Xm, - Xj) 

s'GS j—0 Xj—0j 

where /3 q = /3m+i = 0 and (ij = 5 ^ for 0 < j ^ m. Note that the resulting 
integrals are easily solved because they only involve exponential distributions. 
So, discretization is used merely to restrict the impact of possible state changes 
to the interpolation points xq, • . . ,xat. The influence of the number of interpo- 
lation points on the accuracy and the run-time of the algorithm is one of the 
interesting aspects discussed in Section 4. 

As in [17] for until and time-bounded until some pre-processing is done (on 
the underlying graph G of CTMC M.) before the actual model checking is car- 
ried out. First we determine the set of states for which the (fair) CTL-formula 
3{d>xU<d>2) is valid, i.e. we compute Sat{3{<l>iU <p 2 )) ■ This is done in the usual 
iterative way [17]. For states not in this set the respective probabilistic until- 
formula will have probability 0. In a similar way, we compute the set of states 
for which the probability of these properties will be 1 . This is done by computing 
the set of states Safc(V(^i (up to fairness, cf. [9]) in the usual iterative 

way [17]. As a result, the actual computation, being it the solution of the linear 
system of equations in case of an unbounded until, or the solution of the system 
of Volterra integral equations in case of the time-bounded until, can be restricted 
to the remaining states. This not only reduces the number of states, but also 
speeds up the convergence of the iterative algorithms. 
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Fig. 1. User interface of E F MC^ 
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3.2 Tool Architecture 

E h MC^ has been written entirely in Java (version 1.2), an object-oriented 
language known to provide platform independence and to enable fast and efficient 
program development. Furthermore, support for the development of graphical 
user interfaces as well as grammar parsers are at hand. For the sake of simplic- 
ity, flexibility and extensibility we abstained from low-level optimizations, such 
as minimization of object invocations. The design and implementation took ap- 
proximately 8 man-months, with about 8000 lines of code for the kernel and 
1500 lines of code for the GUI implementation, using the Swing library. The 
tool architecture consists of five components, see Fig. 2. 




Fig. 2. The tool architecture 



Graphical User Interface (cf. Fig. 1) enables the user to load a model A4, a 
labelling L, and the properties to be checked. It prints results on screen or 
writes them into file and allows the user to construct CSL-formulas by the 
‘CSL Property Manager’. Several verification parameters for the numerical 
analysis, such as solution method, precision e and number of interpolation 
points N, can be set by the user. 

Tool Driver controls the model checking procedure. It parses a CSL-formula 
and generates the corresponding parse tree. Subsequent evaluation of the 
parse tree results in calls to the respective verification objects that encap- 
sulate the verification sub-algorithms. These objects, in turn, use the anal- 
ysis and/or numerical engine. For instance, checking V^p{>PiU >p 2 ) involves 
a pre-processing step (as mentioned above) that isolates states satisfying 
3(^1 U <^ 2 ) and V(<?i U<p 2 )- The results of this step are passed to the numer- 
ical engine that computes the corresponding (non-zero) probabilities. 
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Numerical Engine is the numerical analysis engine of E h It computes 

the solution of linear systems of equations and of systems of Volterra integral 
equations in the way explained above on the basis of the parameters provided 
by the user via the GUI, such as the precision e, the ‘maximum loop count’ 
(the maximal number of iterations before termination), or the number N of 
interpolation points used for the piecewise integration. 

Analysis Engine is the engine that supports graph algorithms, for instance, to 
compute the BSCC in case of steady-state properties, and standard model 
checking algorithms for CTL-like until- formulas. The latter algorithms are 
not only used as a pre-processing phase of checking until-formulas (as ex- 
plained above), but they also take care of instances of the special cases 
and VyQ{i~p) where the numerical analysis tends to produce ‘wrong’ 
results (such as 0.99999 . . . rather than 1.0) due to machine imprecision. 

State Space Manager represents DTMCs and CTMCs in a uniform way. In 
fact, it provides an interface between the various checking and analysis com- 
ponents of E h and the way in which DTMCs and CTMCs are ac- 

tually represented. This eases the use of different, possibly even symbolic 
state space representations. It is designed to support input formats of var- 
ious kinds, by means of a simple plug-in-functionality (using dynamic class 
loading) . It maintains information about the validity of atomic propositions 
and of sub-formulas for each state, encapsulated in a ‘Sat’ sub-component. 
After checking a sub- formula, this sub-component stores the results, which 
might be used later. In the current version of the tool, the state space is 
represented as a sparse matrix [27]. The rate matrix R (and its transposed 
) is stored, while the entries of E and P are computed on demand. All 
real values are stored in the IEEE 754 floating point format with double 
precision (64 bit). 



4 Application Case Studies 

In this section we report on experiences with E h MC^ in the context of model 
checking two Markov chain models that have been generated from high-level 
formalisms, namely queueing networks and generalized stochastic Petri nets. 
Based on these experiments we assess the sensitivity of the model checker with 
respect to various parameters. We ran the experiments on a 300 MHz SUN 
Ultra 5/10 workstation with 256 MB memory under the Solaris 2.6 operating 
system. In the case studies we solve linear systems of equations by means of the 
GauB-Seidel method. All recorded execution times are wall clock times. 



4.1 A Simple Tandem Queue 

As a first, simple example we consider a queueing network (with blocking) taken 
from [23] . It consists of a M/ C 0 X 2 / 1-queue sequentially composed with a M/M/ 1- 
queue, see Fig. 3. Due to space constraints, we have to refer to [12] for a thorough 
introduction to networks of queues. Both queueing stations have a capacity of c 
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Fig. 3. A simple tandem network with blocking [23] 



jobs, c > 0. Jobs arrive at the first queueing station with rate A. The server 
of the first station executes jobs in one or two phases; that is, with probability 
1 — oi a job is served with rate only, and with probability ai, the job has to 
pass an additional phase with rate ^ 2 - Once served, jobs leave the first station, 
and are queued in the second station where service takes place with rate k. In 
case the second queueing station is fully occupied, i.e. its server is busy and its 
queue is full, the first station is said to be blocked. Note that in this situation, 
the second phase of the first server is blocked and the first server can only pass 
a job that just finished the first phase to the second phase (which happens 
with probability oi), but the “bypass” of the second phase is also blocked. For 
the experiments we take the following values for the parameters of the queue: 
A = 4 • c, /ii = 2, /i 2 = 2, K = 4, and ai = 0.1. We consider c = 2, which amounts 
to 15 states and 33 transitions, c = 5, i.e. 66 states and 189 transitions and 
c = 20, i.e. 861 states and 2851 transitions. The following atomic propositions 
are considered: 

— full is valid iff the entire tandem network is entirely populated, i.e. iff both 
queueing stations contain c jobs, 

— fst is valid iff no new arriving job (with rate A) can be accepted anymore, 
because the first queue is entirely populated. 

— snd is valid iff the first queueing station is blocked, because the second queue 
is entirely populated. 

It should be noticed that full characterizes a single state, and hence, for large c 
identifies a rare event, i.e. a situation that appears with very low probabil- 
ity. The following steady-state properties are checked: Si^p{full), 5^p(/st), and 
snd)), for arbitrary p and q. The latter property is valid if the steady- 
state probability to be in a state that can reach a state in which the first queueing 
station is blocked in a single step with probability cxi q satisfies ixi p. We do not 
instantiate p and q, as the execution times and computed probabilities will be 
the same for all p and q (except for the extremal cases 0 and 1); only the com- 
parison with the bounds might lead to a different outcome. Thus, p,q €]0,1[. 
For the steady-state properties we vary the precision e of the computed proba- 
bility, which is a parameter to the model checker. The results are listed in Table 1. 

The third column indicates the number of iterations needed to reach the result 
with the desired precision. Recall that the model checker checks the validity of 
CSL-formulas for all states in the CTMC. 

The following probabilistic path properties are checked: Vc<ip{^^*full), 
'Pt^pi^^^fst) and Vc^p{sndU^* ^snd). The latter property refers to the prob- 
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Table 1. Statistics for checking steady-state properties on the tandem queue 



^ states 


e 


^ iterations 


time (in sec) 


‘^DXp 

time (in sec) 


‘5xip (T^xg (.^ snd)) 
time (in sec) 


15 


10-" 


62 


0.012 


0.012 


0.013 




10"*^ 


107 


0.016 


0.017 


0.016 


(c = 2) 


10"® 


146 


0.017 


0.018 


0.019 


66 


10"“ 


77 


0.028 


0.028 


0.065 




10"® 


121 


0.041 


0.042 


0.076 


(c = 5) 


10"® 


159 


0.048 


0.085 


0.181 


861 


10"^ 


74 


0.569 


0.498 


1.567 




10"® 


118 


0.644 


0.643 


1.935 


(c = 20) 


10"® 


158 


0.811 


0.778 


2.369 



Table 2. Statistics for checking ^ 2 )-formulas on the tandem queue 







^ interpolation 


■Pxp(o%V«zO 


•Pxp(0%V-5t) 


'Ptxp('5n(iW^* -isnd) 


^ states 


t 


points 


^ iter. 


time (in sec) 


^ iter. 


time (in sec) 


^ iter. 


time (in sec) 


15 


2 


64 


18 


2.497 


11 


1.045 


4 


0.144 






128 


18 


9.762 


11 


4.082 


4 


0.566 






256 


18 


22.19 


11 


16.30 


4 


2.248 






512 


18 


156.2 


11 


69.04 


4 


9.067 


(c=2) 




1000 


18 


602.3 


11 


248.6 


4 


34.27 


15 


10 


64 


45 


6.506 


12 


1.140 


4 


0.145 






128 


43 


24.00 


12 


4.575 


4 


0.568 






256 


43 


52.85 


12 


17.94 


4 


2.309 






512 


43 


383.1 


12 


75.13 


4 


8.994 


(c=2) 




1000 


43 


1433 


12 


274.9 


4 


34.38 


15 


100 


64 


472 


104.6 


12 


2.133 


4 


0.229 






128 


344 


284.9 


12 


7.682 


4 


0.817 






256 


285 


958.1 


12 


31.07 


4 


3.361 






512 


260 


3582 


12 


123.8 


4 


13.51 


(c=2) 




1000 


252 


13201 


12 


493.8 


4 


51.49 


861 


2 


64 


36 


448.3 


29 


347.3 


21 


9.608 






128 


36 


1773 


29 


1336 


21 


38.90 






256 


36 


7028 


29 


5293 


21 


150.5 


(c = 20) 




512 


36 


28189 


29 


21914 


21 


600.1 



ability of leaving a situation in which the second queue is entirely populated. All 
path-properties are checked with precision e = 10“®. We vary the time-span t 
(over 2, 10 and 100), and the number of interpolation points for the piecewise 
integration from 64 up to 1000. The results for c = 2 are listed in the upper part 
of Table 2. Note the difference in computation time for the different properties. 
Whereas V\^p{sndU^* -^snd) can be checked rather fast, calculating the proba- 
bility for reaching a fst-state within a certain time bound, and — in particular 
— until reaching a full-sta,te takes significantly more time. Since the CTMC 
is strongly connected, a full- or /sf-state can (eventually) be reached from any 
other state, and hence for all states the probability for reaching these states 
within time t must be calculated. In addition, the probability of reaching the 
single full-state is low, especially for larger c, and quite a number of iterations 
are needed in that case to obtain results with the desired precision. Since there 
are several /sf-states in the CTMC, this effect is less important for 
For the last property (last two columns), probabilities need only be computed 
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for snd-states rather than for all states, and precision is reached rather quickly 
as the real probabilities are close to 1 . These effects become more apparent when 
increasing the state space. This is reflected by the results in the lower part of 
Table 2 where we considered a CTMC of almost 1000 states. 



4.2 A Cyclic Server Polling System 




In this section, we consider a cyclic server polling system consisting of d stations 
and a server, modelled as a GSPN."*’ The example is taken from [25], where a 

detailed explanation can be found. For d = 2, 
i.e. a two-station polling system, the GSPN 
model is depicted on the left. For a d-station 
polling system, the Petri net is extended in the 
obvious way. Place idlci represents the condi- 
tion that station i is idle, and place busyi rep- 
resents the condition that station i has gen- 
erated a job. The server visits the stations in 
a cyclic fashion. After polling station i (place 
polli) the server serves station i (place servci), 
and then proceeds to poll the next station. 
The times for generating a message, for polling 
a station and for serving a job are all dis- 
tributed exponentially with parameters Xi , 
and Hi, respectively. In case the server finds 
station i idle, the service time is zero which is modelled by the immediate tran- 
sition skipi and the inhibitor arc from place busyi to transition skipi. In this 
study we consider polling systems with d= 3, 5, 7 and 10 stations (like in [25]). 
The corresponding GTMGs have 36, 240, 1344 and 15360 states (84, 800, 5824 
and 89600 transitions). The polling systems are assumed to be symmetric, i.e. all 
Xi have the same numerical values, and the same is true for all 7 ^ = 1 and all 
Hi = 200. We set Xi = Hi/d. 

In the context of GSPNs, it is rather natural to identify the set of places that 
possess a token in a given marking — i.e. a state of our GTMG — with the set of 
atomic propositions valid in this state. Based on these atomic propositions, we 
check the following properties on the polling system: ^{polli AP 0 U 2 ), stating that 
the server never polls both stations at the same time; Vt^p{-^serve 2 U servei), 
i.e. with probability cxi p station 1 will be served before station 2 ; busyi => 
V^i{Opolli) , so once station 1 has become busy, it will eventually be polled; 
busyi polli) , once station 1 has become busy, with probability ixi p 

it will be polled within t time units. (We let t = 1.5.) The following steady state 



^ We refer to [1] for details on the semantics of GSPNs. In particular, the existence of 
immediate transitions (i.e. the black transitions) leads to so-called vanishing mark- 
ings in the reachability graph which, however, can be eliminated easily. Our model 
checker works on the resulting tangible reachability graph which is isomorphic to a 
CTMC. 
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formulas are considered: Sx^p{husy\ A ^seruei), which says that the probability 
of station 1 being waiting for the server is ixi p; and Sx^p(idle\)^ stating that 
the probability of station 1 being idle is ixi p. Like before, p €]0,1[. All path- 



Table 3. Statistics for checking CSL-formulas on the polling system 



d 


^ states 


-'{polli A P 0 U 2 ) 
time (in sec) 


V\^p{-'serve 2 lA servei) 
time (in sec) 


busyi ^ 'P^i{Opolli) 
time (in sec) 


3 


36 


0.002 


0.031 


0.005 


5 


240 


0.002 


0.171 


0.009 


7 


1344 


0.005 


1.220 


0.011 


10 


15360 


0.037 


16.14 


0.080 



d 


^ states 


busyi - 
^ iter. 


^ V^p{0^^-^polh) 
time (in sec) 


(5r. 
^ iter. 


isyi A — isernei ) 
time (in sec) 


»S[> 

^ iter. 


!^p{idlei) 
time (in sec) 


3 


36 


8 


2.308 


39 


0.044 


39 


0.038 


5 


240 


12 


30.92 


61 


0.103 


61 


0.102 


7 


1344 


14 


308.5 


80 


0.677 


80 


0.658 


10 


15360 


18 


7090 


107 


11.28 


107 


11.29 



properties were checked with precision e = 10“®, and the number of interpolation 
points for numerical integration was set to 64. The steady-state properties were 
checked for e = 10“®. 



4.3 Assessment of the Tool 

Verification time. From the results of our case studies we observe that checking 
CSL-formulas consisting of just atomic propositions and logical connectives is 
very fast. Checking steady-state properties and unbounded until-formulas is also 
a matter of only a few seconds, even for the 15360 state case. Measurements have 
shown that the performance of our tool’s steady-state solution algorithm is com- 
parable to the one of TIPPtool [22] which is based on a sophisticated sparse ma- 
trix library implemented in C. The model checking algorithm for time-bounded 
until Vp<jp{'PiU^* (P 2 ), which involves the approximate solution of a system of 
integral equations, becomes very time consuming for larger state spaces. Ob- 
viously, the execution times for checking time-bounded until strongly depend 
on the chosen number of interpolation points: each iteration in the piecewise 
integration in the worst case is of order 0{N'^ ■ K), where K is the number of 
transitions and N the number of interpolation points. In addition, the execution 
times depend on the arguments (i.e. <l>i and ^ 2 ) and the considered time-span 
(i.e. parameter t). For instance, checking V^p{0^*<p2) involves a computation 
for each state (that has a non-zero and non-trivial probability of reaching a 
<? 2 -state), while checking V^p(aU^^ < 1 > 2 ) only involves a computation for the a- 
labelled states (of this set). The case studies, and other experiments which we 
conducted showed that the main performance bottleneck of our tool is the algo- 
rithm for time-bounded until. 

Accuracy of numerical results. In order to assess the numerical accuracy of 
the algorithm for time-bounded until, we used our tool to compute (amongst 
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others) the cumulative distribution function of the Erlang A:-distribution, that 
is, a convolution of k identical exponential distributions. For small k the results 
of the iterative algorithm are quite accurate, even for a small number of interpo- 
lation points N . The accuracy further improves as N is increased, as expected. 
For k ^ 100 and small N , the accuracy of the results is unacceptable, while for 
larger N the run-time becomes excessive. 

Accuracy of verification result. Another issue — that is inherently present 
in all model checking approaches that rely on numerical recipes — is to avoid 
wrong outcomes of comparisons with a probability bound p in a sub-formula, 
that is then propagated upwards. Because round-off and truncation errors can- 
not be avoided (due to machine imprecision), this effect can happen if the com- 
puted value is very close to the bound p. For the extremal probability bounds 
(i.e. bounds > 0 and 1), we have circumvented this problem by applying the 
standard model checking algorithms for V and 3 as in [17]. Furthermore we in- 
tend to use a three-valued logic such that the tool can avoid potentially wrong 
results, and answers ‘don’t know’ in case some calculated (i.e. approximated) 
probability is within some tolerance to a probability bound p occurring in a 
(sub-)formula to be checked. 

5 Conclusion 

In this paper we have presented a model checker for (state labelled) discrete and 
continuous-time Markov chains. We reported on the structure of the tool, and on 
experiments using the model checker to verify CTMCs derived from high-level 
formalisms such as stochastic Petri nets and queueing networks. As far as we 
know, E h is the first implementation of a bridge between such high-level 

specification formalisms for CTMCs and model checking. 

E h MC^ is a prototype, in particular for the moment it does not use sym- 
bolic, i.e. (MT)BDD-based, data structures. Although our own experience (and 
of others, cf. [16]) has shown that very compact encodings of Markov chains are 
possible with MTBDDs and similar data structures [23], and symbolic model 
checking algorithms for CTMCs do exist [8], we favor a separation of concerns: 
to our belief the issues of numerical stability, convergence, accuracy and efficiency 
are worth to be studied in isolation, without interference of the (sometimes un- 
predictable) effects of BDD-based computations. In addition, none of the high- 
level modelling tools for generating CTMCs uses BDD-based data structures, as 
far as we know. 

Our decision to implement the model checker E h MC^ in Java turned out 
to be a good choice. In particular it allowed us to develop an easy-to-use user 
interface along with the model checker engine. Also the numerical computations 
have a good performance in Java; e.g., the computation of steady-state proper- 
ties is comparable to (optimised) existing C implementations. Our experiments 
with E h have shown that the checking of time-bounded until-properties 

requires an efficiency improvement. We are currently considering alternative 
ways to model check this operator [7] . 
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Abstract. We present an attempt to use the model checker Spin as a 
verification engine for SDL, with special emphasis put on the verifica- 
tion of timing properties of SDL models. We have extended Spin with a 
front-end that allows to translate SDL to Promela (the input language 
of Spin), and a back-end that allows to analyse timing properties. Com- 
pared with the previous attempts, our approach allows to verify not only 
qualitative but also quantitative aspects of SDL timers, and our trans- 
lation of SDL to Promela handles the SDL timers in a correct way. We 
applied the toolset to the verification of a substantial part of a complex 
industrial protocol. This allowed to expose several non-trivial errors in 
the protocol’s design. 



1 Introduction 

We present an approach to automating the formal verification of SDL, by model 
checking SDL specifications with Spin. SDL [8] is a visual specification language, 
especially well suited for communication protocols, and quite popular in industry. 
Spin [5] is one of the most successful enumerative model checkers. 

In order to connect the Spin verification engine to SDL, we had to extend 
Spin in two ways. First, we had to implement a front-end which would allow to 
automatically translate SDL to Promela (the input language of Spin). Second, 
we had to extend Spin with the notion of discrete time, to be able to model SDL 
timers. The extended version is called DT Spin and its input language is called 
DT Promela (where DT stands for discrete time). 

The translation of SDL to Promela is split into two steps. In the first step 
we use the sdl2if tool, implemented in Verimag, Grenoble, which transforms 
SDL programs to the intermediate format IF [3] that was designed for the repre- 
sentation of timed asynchronous systems. This first step flattens the hierarchic 
structure of SDL blocks to bare processes which can then be directly transformed 
to Promela processes, in the second step, by our tool if2pml. 

* This research has been supported by the VIRES project (Verifying Industrial Reac- 
tive Systems, Esprit Long Term Research Project ^23498). 
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We applied our method to the verification of a substantial part of MAS- 
CARA which is a complex telecommunication protocol developed by the WAND 
(Wireless ATM Network Demonstrator) consortium [13]. As a result, we exposed 
several non-trivial errors in the design of MASCARA. 

In order to resolve the usual problems caused by the lack of the formal 
semantics of SDL, we decided to rely on the semantics of SDL as determined 
by the ObjectCEODE tool [11]. In particular, we assume that transitions are 
atomic and instantaneous, and timeout signals are not necessarily sent at the 
beginning of a time slice (in other words, the timer messages are treated like other 
messages, without any special priority). More details are given in Section 3.2. 

We are aware of two other attempts to use Spin as a verification engine 
for SDL [6,10]. In our opinion, they were not fully successful. First, both ap- 
proaches tackle the qualitative aspects of SDL timers only, in the sense that 
they abstract out the concrete values of timers. Our approach allows to analyze 
the quantitative aspects of SDL timers as well. Second, the previous approaches 
are incorrect, as far as the timing issues are concerned. More precisely, instead of 
just introducing more behaviours, which is unavoidable when the concrete values 
of timers are abstracted out, they simultaneously remove some of the behaviours 
that are allowed by SDL, which may lead to unsound results (so called “false 
positives”). Some concrete examples are given in Section 3.3. The incorrectness 
of the previous attempts also shows that taking the timing issues of SDL into 
account, when using Spin to model check SDL, is not trivial. 

We do not claim that our approach is correct, in the formal sense. Ideally, 
one should prove that the approach is sound (no “false positives” are possible) 
and complete (no “false negatives” are possible). In principle, such a correctness 
result cannot be established, due to the lack of formal semantics, both for SDL 
and Promela, which would be simple enough to carry such correctness proofs. 
However, we give some informal justification of the correctness of our approach. 

We clearly separate the qualitative and quantitative aspects of SDL timers. 
This allows to analyze the SDL models that use timers, both in the abstract 
and concrete way. The two methods have their own benefits and drawbacks. 
In the abstract case, if DT Spin decides that some safety property holds then 
the property is true for all values of timers, and is thus time independent. This 
may be a desired feature of a model. On the other hand, proving the time 
independence may come at a price: “false negatives” are possible, in the case a 
property does depend on time. The analysis with the concrete values of timers 
does not lead to “false negatives” , but the price may be a bigger state space that 
must be enumerated by DT Spin. 

We put some effort in making DT Spin a “conservative” extension of Spin: 
DT Promela is designed in such a way that standard Spin can be used to model 
check DT Promela programs obtained from the SDL models with abstracted 
timers. This may be useful for those who prefer to use a proven technology, 
instead of our experimental DT Spin. 

The paper is organized as follows. In Section 2, we give an overview of Spin 
and DT Spin. Section 3 is devoted to the translation of SDL to DT Promela. The 
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verification method and its application to the MASCARA protocol is presented 
in Sections 4 and 5. Finally, we conclude with Section 6. 

2 Spin and DT Spin 

2.1 Spin and Promela 

Spin [5] is a software tool that supports the analysis and verification of concurrent 
systems. The system descriptions are modelled in a high-level language, called 
Promela. Its syntax is derived from C, and extended with Dijkstra’s guarded 
commands and communication primitives from Hoare’s CSP. 

In Promela, system components are specified as processes that can interact 
either by message passing, via channels, or memory sharing, via global variables. 
The message passing can either be buffered or unbuffered (as in Hoare’s CSP). 
Concurrency is asynchronous (no assumptions are made on the relative speed of 
process executions) and modelled by interleaving (in every step only one enabled 
action is performed). 

Given a Promela model as input. Spin generates a C program that performs 
a verification of the system by enumerating its state space, using a depth- first 
search algorithm. This way, both safety properties (such as absence of deadlock, 
unspecified message receptions, invalid end states, and assertions) and liveness 
properties (such as non-progress cycles and eventual reception of messages) can 
be checked. The most general way of expressing properties in Spin is via so-called 
never claims, which are best seen as monitoring processes that run in lock step 
with the rest of the system. The never claims are, in fact, Biichi Automata, and 
thus can express arbitrary omega-regular properties. Spin provides an automatic 
translator from formulae in linear-time temporal logic (LTL) to never claims, so it 
can be used as a full LTL model checker. In case the system violates a property, 
the trace of actions leading to an invalid state, or a cycle, is reported. The 
erroneous trace can be replayed, on the Promela source, by a guided simulation. 

To cope with the problem of state space explosion. Spin employs several 
techniques, such as partial-order reduction, state-vector compression, and bit- 
state hashing. 



2.2 DT Spin and DT Promela 

DT Spin [2] is an extension of Spin with discrete time. In the time model used in 
DT Spin, time is divided into slices indexed by natural numbers that can be seen 
as readings of a fictitious global digital clock that ticks at the end of each slice. 
The events happening in the same slice are assigned the same clock value, so 
the elapsed time between events is measured in ticks. In our model, time passes 
only if no other action in the system is possible. 

Since concurrency is modelled by interleaving, all the events happening in one 
run of a system are totally ordered and thus two events happening in the same 
slice are not considered necessarily simultaneous. Instead, they are considered 
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to be ordered, and their ordering inside one slice is determined by the ordering 
of the run. The properties that depend only on the ordering of events are called 
qualitative while those depending on the elapsed time between events are called 
quantitative. 

In order to capture timing features, standard Promela is extended to DT 
Promela. A new data type, called timer, is introduced. It is used to declare 
variables that represent discrete-time countdown timers. Three new statements 
that operate on timers are added: set (.tmr,val) activates the timer tmr, by 
assigning the integer value val to tmr, reset (tmr) deactivates tmr, by setting 
it to —1, and expire (tmr) tests whether the value of tmr is 0. Initially, a timer 
has value —1. 

In fact, the new statements are defined as Promela macros, in a special header 
file included at the beginning of every DT Promela model: 



#define timer 
#define set (tmr, val) 
#define reset (tmr) 
#define expire (tmr) 



short /* a short integer */ 
tmr = val 
tmr = -1 
tmr == 0 



The new statements allow to model a broad class of timing constraints, and 
other timed statements can easily be defined as Promela macros, by combining 
set, reset and expire with the control flow statements offered by Promela. 
There is yet another operation on timers: the tick statement decreases the 
value of all active timers by 1. It is used internally by DT Spin, at the end of 
every time slice, and is not available to the user. 

DT Spin is fully compatible with Spin, and all features of Spin can be used 
to analyse discrete-time models. In particular, the partial order reduction algo- 
rithm of Spin [7,9] had to be adapted for timed systems [2]. Besides qualitative 
properties, a broad range of quantitative properties can be verified using boolean 
expressions on timer values, in the assertions and LTL formulae. 



3 Translating SDL to DT Promela 

The process of model checking an SDL specification is depicted in Figure 1. An 
SDL specification is pushed through the pipe of translators sdl2if and if2pml, 
to obtain a DT Promela program that serves as input to DT Spin or Spin. The 
result of a negative verification experiment (e.g., an erroneous trace) has to be 
checked manuaily against the SDL specification. 

sdl2if transiates SDL to the language IF (Intermediate Format, [3]) which 
is a specification language for timed concurrent systems consisting of a fixed 
number of communicating automata. IF was designed as an intermediate for- 
malism for connecting several industrial formal description techniques, such as 
LOTOS and SDL, to a number of verification tools developed in the research 
community. 

sdl2if is implemented with the help of the SDL/ API Interface provided by 
the ObjectGEODE tool [11]. The current implementation of sdl2if is able to 
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Fig. 1. The tools used in the verification. 



translate a substantial subset of SDL. The only essential omissions are dynami- 
cally created processes and abstract data types. 

In the overall SDL to DT Promela translation, sdl2if resolves the hier- 
archical aspects of SDL by “flattening” the hierarchy of blocks down to bare 
processes and resolving appropriately the sources, destinations and priorities of 
the signals exchanged between the processes. On the way, the SDL procedures 
are eliminated by inlining (when possible), and the syntactic sugar of SDL (en- 
abling conditions, continuous signals, the special input none) is transformed to 
more primitive constructs. Moreover, some implicit constructs are made explicit 
(sender, offspring, parent, discarded signals). Details are given in [3]. 

On the other hand, if2pml performs the translation of the SDL core lan- 
guage, coping with issues that have more semantical flavor (like preserving the 
atomicity of the transitions or implementing the discard mechanism) . Since IF is 
intended to be an intermediate language for a variety of high-level specification 
formalisms, it is quite expressive. As not all of its constructs are needed for rep- 
resenting SDL models, if2pml only translates the subset of IF that is relevant 
to SDL. 

IF and sdl2if were developed at Verimag, Grenoble, while if2pml and DT 
Spin were developed at the Eindhoven University of Technology. All the tools 
were developed in the framework of the VIRES project [12]. 

In what follows we describe the translation from IF to DT Promela in more 
detail. The presentation is divided into three parts. In Section 3.1 we describe 
how the SDL processes (i.e., IF automata) are represented in Promela. In Sec- 
tion 3.2, the DT Promela representation of the SDL/IF timers is given. Finally, 
in Section 3.3, the abstraction from the concrete values of timers is described. 

3.1 IF to Promela: Translating Automata 

As in Promela, the IF models are sets of processes that communicate via buffers. 
This provides an almost one-to-one translation of these concepts. Also, the IF 
data types can directly be translated to their Promela counterparts (with some 
minor restrictions on the range types). 
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The way the SDL/IF automata are represented in Promela is fairly standard, 
and can be grasped by comparing the IF source given in Fig. 2 with its Promela 
translation in Fig. 3. A state is represented by a Promela label. All the outgoing 
transitions are translated to the branches of the choice statement associated 
with the label. The discard mechanism is implemented via self-looping to the 
same state, after reading a signal that has to be discarded in the state. The 
atomicity of SDL/IF transitions is preserved by putting the if statement inside 
the atomic statement.^ 



process proc: buffer buf ; 
state 

statel discard sig3, sig4 in buf 
state2 

transition 

from statel input sigl from buf do bodyl to state2; 
from statel input sig2 from buf do body2 to stateS; 



Fig. 2. A skeleton of an IF program. 



proctype procO { 
statel: atomic { 
if 

:: buf?sigl -> translated_bodyl ; goto state2; 
:: buf?sig2 -> translated_body2; goto stateS; 



:: buf?sig3 -> goto statel; /* discard */ 
:: buf?sig4 -> goto statel; /* discard */ 
fi 



state2: atomicf 
} 



Fig. 3. Promela translation of the structure from Fig. 2 



The implementation of if2pml is still in a prototype stage and some SDL 
features are not supported yet. The most notable omissions are the mechanism of 
saving a signal, the dynamic creation of processes, and the abstract data types. 
The implementation of the save mechanism in Promela is possible, but rather 

^ A special care is taken to correctly handle the stable and non-stable states in IF. 
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involved. It may lead to a substantial growth of the state space during model 
checking, and for this reason we have chosen to omit it. The dynamic process 
creation is a basic feature of Promela, so it can easily be implemented once 
sdl2if supports it. Finding a satisfactory solution for the abstract data types 
remains a future work for both sdl2if and if2pml. 

3.2 IF to DT Promela: Translating Timers 

The crucial issue about time in SDL is the detection of timer expirations (time- 
outs). In SDL, a timer expiration results in sending a timeout pseudo-signal 
to the input queue of the process the timer belongs to. The timeout signal is 
then handled as an ordinary signal: it is either consumed, by a transition that is 
guarded by the timeout signal, or discarded, in a state with no such transitions. 
In both cases, the corresponding timer is deactivated. 

Our implementation of timers does not use such timeout signals. Instead, 
we associate with each SDL timer a DT Promela timer variable, and detect the 
expiration of the timer by testing whether the timer variable has value 0, and 
the timer is deactivated by setting the timer variable’s value to —1. 

More precisely, for each timer tmr declared in an SDL process, we add a new 
branch to all the choice statements associated with states (see figure 3) . Assume 
a state, say state 1, with an outgoing transition guarded by tmr. For such a 
state we add the branch 

:: expire (tmr) -> reset (tmr); translated_bodyl ; goto state2; 

If state 1 has no outgoing transitions guarded by tmr, we add the branch 
:: expire (tmr) -> reset (tmr); goto statel; /* discard */ 

It turns out that under the time semantics given below (as determined by 
the ObjectGEODE tool [11]), these two approaches to timers are equivalent. 
However, the “variable” approach has an advantage over the “signal” approach, 
from the verification point of view, since it generates smaller state spaces. In 
the “signal” approach, an additional Promela process (or even several processes) 
would be needed, in order to generate the timeout signals in a right way. This, 
together with the overhead of exchanging timeout signals, increases the state 
space. 

In what follows, we give an informal justification of the above mentioned 
equivalence. 

The semantics of time in SDL. Transitions are instantaneous. Time can 
only progress if at least one timer is active and all SDL processes are waiting 
for further input signals (i.e., all input queues are empty, except for saved sig- 
nals). Time progression amounts to performing a special transition that makes 
time increment until an active timer expires. In the sequel, we refer to the seg- 
ments of time separated by the special transition as time slices. (Note that time 
progression is discretized.) 
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With each timer there is associated a pseudo-signal and an implicit transition, 
called a timeout transition. When a timer expires, in some time slice, its timeout 
transition becomes enabled and can be executed at any point of the time slice. 
The execution of this transition adds the associated pseudo-signal to the process 
queue. The timeout transitions of the timers that expire simultaneously can be 
executed in any order. 

If the set or reset operation is performed on a timer after its timeout 
transition becomes enabled, the timeout transition is disabled. If the timer is 
set or reset after adding its associated pseudo-signal to the process queue, the 
pseudo-signal is removed from the queue. 

Model equivalence. In order to justify the equivalence of the two models we 
need to show that any execution sequence in the signal model can be simulated 
by an execution sequence in the variable model, and vice versa. In what follows, 
we assume that SDL timers are never set to the special value now (i.e., our timer 
variables are never set to 0, explicitly) , and we only concentrate on the simulation 
of the transitions which relate to timers, since the two models coincide on the 
untimed features. There are two issues which have to be considered: the set and 
reset operations on timers, and the expiration of timers. 

The set and reset operations coincide in the two models, so this issue does 
not cause problems. As far as the expiration of timers is concerned, it should be 
obvious that the time slice in which a timer expires is recognized in the same 
way, in both models. 

The only problematic issue is whether consuming/discarding the timeout 
signals, in the signal model, is properly simulated with our count-down timers, 
and vice versa. Our claim that, in fact, this is the case is based on the assumption 
that the following, more direct, translation of SDL/IF to Promela would be 
correct . 

Assume ts-T denotes the timeout signal corresponding to timer T, in the 
signal model. In order to handle the consumption of ts-T like the consumption 
of an ordinary signal, by an SDL/IF transition guarded by ts-T, the following 
branch 



:: buf?ts_T -> translated_bodyl ; goto state2; 

could be added to the Promela translation in figure 3. 

Similarly, in order to handle the discarding of ts-T as an ordinary signal, the 
following branch 

:: buf?ts_T -> goto statel; /* discard */ 

could be added to the choice statements that corresponds to the states with no 
outgoing transitions guarded by ts-T. 

Observe that the 

: : expire (tmr) -> reset (tmr) ; ... 
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branches, in our real Promela code, correspond directly to the above branches. 
More precisely, expire (tmr) -> reset (tmr) corresponds directly to buf?ts_T. 
Namely, expire (tmr) corresponds to the check whether ts-T is in the input 
queue, and reset (tmr) corresponds to the removal of ts-T from the queue. 



3.3 Timer Abstraction 



It turns out that standard Spin can also be used to model check a DT Promela 
model, for a property that does not depend on time. The advantage of using 
Spin instead of DT Spin is that Spin usually consumes less resources than DT 
Spin. In order to convert a DT Promela model into a Promela model, it suffices 
to change the special header file included at the beginning of every DT Promela 
model (see Section 2.2): 



#define timer 
#define set(tmr,val) 
#define reset (tmr) 
#define expire (tmr) 



bool 

tmr = true 
tmr = false 
tmr == true 



The new definitions abstract out the concrete values of active timers, by 
consistently mapping them to true. The concrete value —1, which is used to 
mark an inactive timer, is consistently mapped to false (under the assumption 
that each timer is initialised to false). Obviously, such an abstraction is sound 
since no behaviours are lost. More precisely, any behaviour with concrete timers 
can be simulated with abstract timers, since the active timers are allowed to 
expire nondeterministically, at any time. 

This is not the case in the related approaches [6,10], where some heuristic 
approximations of the timer behaviour are used rather than a proper abstraction. 
The approximations do not only add some behaviours, but also loose some of 
them, as shown in the following examples. 

In [6] the authors try to minimize the number of timer expirations, in the 
abstract system, that do not correspond to expirations in the concrete system. 
They take advantage of the observation that, in practice, the transitions guarded 
by a timer expiration are supposed to resolve the kind of deadlocks when no other 
transitions except the ones triggered by timeout signals would be enabled. The 
timers are represented by processes that send the corresponding timeout signals 
when the special Promela statement timeout becomes enabled. The timeout 
statement becomes enabled when no other transition is enabled, in the system. 

However, there are situations when a behaviour of the concrete system cannot 
be simulated by the approximate one. Let us consider two concurrent processes, 
say P\ and P 2 , specified by the following transition systems: 



TiM B/ 

P\ : • > • > • 



P2 : • 



A/ 

• > • 



T2/B 
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where T\ and T2 are timer signals, A and B are normal signals, and X/Y denotes 
“receive X and send Y to the other process” . 

If both T\ and T2 expire simultaneously then, in the concrete system, P\ 
and P2 may exchange signals A and B, and both reach their final states. However, 
in the abstract system, one of the processes will not be able to reach its final 
state. Initially, the first transitions of both processes are enabled. If Pi performs 
its first transition (and thus sends A to P2), the first transition of P2 becomes 
disabled. P2 must discard A, before its first transition becomes enabled again, 
and thus it will not be able to pass the Aj guard. Similarly, if P2 performs its 
first transition, P\ will not be able to pass the B/ guard. 

In the approximation used in [ 10 ], one pseudo-process is used to handle all 
timer expirations. After each set operation this pseudo-process immediately 
sends the corresponding timeout signal to the input queue of the process that 
sets the timer. As a result, if an SDL process uses two timers, they can only expire 
in the order they are set, no matter what values they are set to. Obviously, the 
behaviour in which an SDL process sets the timers T\ and T2 (in that order) 
to such values that T2 expires before Ti cannot be simulated by the abstract 
system. 



4 Verification Methodology 

The aim of this section is to present the way the real verification process is 
performed. Industrial-size SDL models normally cannot be verified with existing 
model-checking tools as a whole, so the first natural task is to split a protocol in 
some relatively autonomous parts of a reasonable size and apply to them compo- 
sitional verification. Fortunately, due to their block-structure, SDL-systems can 
be usually split in a natural way without much effort. 

The obtained sub-models are not self-contained, i.e. the behaviour of their 
environment is not specified. Since Spin can only model-check closed systems 
we need to close our model first. We achieve this by adding an “environment” 
process specified in SDL at the same hierarchy level as the extracted model itself. 

The simplest possible approach is to construct an environment producing all 
the “possible” behaviours but practice shows that this is not of much use in 
real life. Such an environment leads to adding to the model too many erroneous 
behaviours and thus one gets too many “false negatives” during model-checking. 
Local livelocks, cycles with non-progressing time, and non-existing deadlocks 
are the typical examples of those false-errors. Moreover, since many redundant 
behaviours are added, this may also lead to a state explosion. Another possibility 
is to construct an environment being able to send/receive a signal whenever the 
modelled system is ready to get/send it. Applying such an approach reduces the 
added behaviours but it still adds some unwanted behaviours caused by sending 
non-realistic signal sequences. 

Both these approaches are not safe: in case of adding non-progressing time 
cycles, we loose some behaviour of the system. So they can be considered as 
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a kind of heuristics only, that may be of some use at the first stage of system 
debugging. 

A different approach is to provide an SDL-specification of the “right” envi- 
ronment, i.e. the one, which faithfully models the assumptions under which the 
component was designed, giving an abstraction of a real environment. Although 
it makes the soundness of verification results dependent on the quality of the 
environment model, it usually turns out to be a practical method. 

The closed SDL-model can be automatically translated into DT Promela 
through the translators sdl2if and if2pml. Then one should choose between 
verification of the concrete model with DT Spin and verification of the model 
with abstracted time in the standard Spin. First, the built-in Spin features (find- 
ing deadlocks and livelocks, unreachable code) are used. After correcting discov- 
ered structural errors, functional properties defined by a designer or drawn from 
the informal specification of the system can be verified. 

It would seem obvious to verify all non-timed properties with an abstracted- 
time model and all timed properties with a concrete model. However, sometimes 
it is more convenient to verify non-timed properties with a concrete model as 
well. If some functional property was proved with the abstracted-time model, 
it is proved for all possible values of timers. However if it was disproved, or a 
deadlock in the model was found, the next step is to check whether the erroneous 
trace given by Spin is a real error in the system or it is a false error caused 
by adding erroneous behaviour either with abstracting from time or with too 
abstract specification of the environment. It can happen that the property does 
not hold for the concrete model, however the erroneous trace given by Spin is 
one of the added behaviours. This behaviour cannot be reproduced for the SDL 
model with SDL-simulation tools and we cannot conclude whether the property 
holds or not. 

One can not force Spin to give the trace from the non-added behaviours. DT 
Spin allows to reduce the set of added behaviours guaranteeing that timers are 
expiring in the correct order. In our verification experiments we had a number 
of cases when application of DT Spin, instead of Spin, gave a chance to get a 
real erroneous trace and disprove the property (see the next section). 



5 Case Study: Verifying the MASCARA Protocol 

We have applied our tools to the verification of an industrial-size communica- 
tion protocol called MASCARA (Mobile Access Scheme based on Contention 
and Reservation for ATM), developed by the WAND (Wireless ATM Network 
Demonstrator) consortium [13]. The protocol is an extension of the ATM (Asyn- 
chronous Transfer Mode) networking protocol to wireless networks. 

A wireless ATM network comprises of a fixed wire-based ATM network that 
links a number of geographically distributed access points, which transparently 
extend ATM services to mobile users, via radio links operating in the 5.2 GHz 
frequency band and achieving data rates of 23.5 MBits/s. The task of MAS- 
CARA is to mediate between the mobile users and the access points, to offer 
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the mobile users the advantages of the standard wire-based ATM protocol: high 
reliability, capacity-on-demand, and service-independent transport. The trans- 
parent extension of ATM over radio links is a challenge, as standard ATM has not 
been designed to work in a wireless environment. The radio medium is charac- 
terised by a high bit error rate, the transmission mode is typically broadcast (or 
at least multicast) and the scarcity of available radio bandwidth calls for a time 
division duplex (i.e. half duplex) mode. All this leads to the necessity of extra 
functionality allowing to cope with these dissimilar environmental properties. 

A crucial feature of MASCARA is the support of mobility. A mobile terminal 
(MT) can reliably communicate with an access point (AP) only within some area 
called the AP’s cell. Whenever an MT moves outside the cell of its current AP 
it has to perform a so-called handover to an AP whose cell the MT has moved 
into. A handover must be managed transparently with respect to the ATM 
layer, maintaining the agreed quality of service for the current connections. So 
the protocol has to detect the need for a handover, select a candidate AP to 
switch to and redirect the traffic with minimal interruption. 

The protocol is too large to be automatically verified as a whole so we have 
concentrated our efforts on the verification of a substantial part called MCL 
(MASCARA Control). The main purpose of MCL is to support the mobility 
issues. It contains 9 processes, each with up to 10 states (6 on average). Its main 
function is to monitor the current radio link quality, gather information about 
radio link qualities of its neighbouring APs (to make a quick handover, in the 
case of deterioration of the current link quality), and switch from one AP to 
another (during the handover procedure). 

During the first phase of the verification, several deadlocks were found. 
Most of them were related to improper synchronisation between various re- 
quest/confirm subprotocols (a component requests a service from another com- 
ponent and waits until the confirmation arrives that the request is either rejected 
or served) . The second source of deadlocks was the potential race conditions be- 
tween various components of MCL, due to the fully asynchronous communication 
in SDL (non-blocking sending of messages) . The following example describes one 
of the race conditions we have found. 

Most MASCARA components must be initialised before they are prepared to 
serve requests from other components. The components are grouped in various 
tree-like hierarchies, and the initialisation phase for a group is triggered by send- 
ing the INIT signal to the group’s root. Each node that receives the INIT signal 
resends the signal to all its children. However, in such a cascade of INIT signals 
there is a possible race condition: Spin found a trace in MCL where an already 
initialised component tried to immediately request a service from a component 
that had not been initialised yet. Such a request was simply discarded and thus 
its confirmation was never sent back, leading to a deadlock in MCL. 

After correcting these errors, we continued the verification, by exploiting 
another useful Spin feature — unreachable code diagnosis. The analysis of the 
unreachable code reported by Spin revealed that some code for serving one par- 
ticular request is never reached and thus the request for that particular service 
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was never confirmed. Further analysis showed that there was a local deadlock 
possible. (This local deadlock could not be discovered by Spin, in previous ex- 
periments, since Spin can only discover global deadlocks.) 

Finally, we verified some functional properties that we derived from the in- 
formal specification. An example of such a property is given below. 

One of the tasks of MCL is to periodically update a list that contains informa- 
tion about the quality of radio links with the neighbouring APs. This updating 
phase is called the TI procedure. In order to judge the quality of a radio link with 
a particular AP, MCL must connect to that particular AP, so the connection 
with the current AP is suspended during the whole TI procedure. Therefore, an- 
other procedure, checking the quality of the current connection and making the 
decision on the necessity of a handover, should not interfere with TI procedure. 

This requirement was encoded as a simple observer for the following safety 
property: a handover request never comes in between the two messages that 
mark the beginning and the end of the TI procedure. The verification experiment 
with Spin, which was supposed to confirm this property, showed instead a trace 
violating it. Unfortunately, the erroneous trace could not be simulated by the 
SDL model of MCL (so we got a so-called “false negative”). However, when 
exactly the same experiment was repeated with DT Spin we got a different 
erroneous trace which could then be simulated by the SDL model. Thus, the 
property was indeed violated, DT Spin allowed us to find yet another error in 
MASCARA protocol. 

The explanation of the different results obtained with Spin and DT Spin is 
obvious. The TI procedure is triggered by a timer, so the behaviour of the TI 
protocol could indeed depend on proper timing. In the model with abstracted 
time, as used in Spin, timers can expire at any time, so Spin can produce a 
wrongly timed trace that is not accepted by an SDL simulator (which allows 
only properly timed traces, of course). After finding a way to re-design the 
components, some other functional properties were proved. 

When we planned the first series of verification experiments we expected 
to reach the limits of Spin and DT Spin quickly. We were proved wrong. In 
the experiment that consumed the most resources, Spin reported the following 
statistics: 

State-vector 416 byte, depth reached 3450, errors: 0 
55959 states, stored 
23.727 memory usage for states (in MB) 

25.582 total memory usage (in MB) 

14.2 total time (in seconds) 

which should be read in the following way: 

State-vector 416 byte is the memory needed to represent one state. 

55959 states , stored is the number of different states found in the model (all 
the states must be kept during the state space enumeration, so 23.727MB 
memory was needed for states). 
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depth reached 3450 is the greatest depth reached during the depth-first search 
(since Spin must keep a state stack of at least this depth, about 1.7MB was 
needed in addition to the state memory). 

It is quite likely that with our 2048MB memory we will be able to handle 
even more complex case studies. 

6 Conclusions and Future Work 

We have developed a tool, if2pml, that enables the translation from SDL to 
Promela. It can be used, together with the accompanying tool sdl2if , to model 
check SDL specifications with Spin. 

Our approach preserves the timing aspects of SDL. This is in contrast to 
other translators that we know, which only approximate timing aspects. SDL 
timers, which expire by sending signals, are in our approach translated into the 
timer variables provided by DT Promela. We have argued the correctness of this 
translation. 

The approach has been successfully used on an industrial case study. More 
information is available from http ; //radon, ics . ele . tue . nl/~vires/public/ 
results. 

As a future work, we consider to extend the tool by implementing the trans- 
lation of dynamic process creation in SDL and the save construct. SDL supports 
various styles of specifying data types. It needs to be investigated how the spec- 
ification of data aspects can be combined with the translation from SDL to 
Promela. 
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Abstract. Salsa is an invariant checker for specifications in SAL (the 
SCR Abstract Language). To establish a formula as an invariant with- 
ont any user guidance. Salsa carries out an induction proof that uti- 
lizes tightly integrated decision procedures, currently a combination of 
HDD algorithms and a constraint solver for integer linear arithmetic, for 
discharging the verification conditions. The user interface of Salsa is de- 
signed to mimic the interfaces of model checkers; i.e., given a formula and 
a system description. Salsa either establishes the formula as an invariant 
of the system (but returns no proof) or provides a counterexample. In 
either case, the algorithm will terminate. Unlike model checkers, Salsa 
returns a state pair as a counterexample and not an execution sequence. 
Also, due to the incompleteness of induction, users must validate the 
counterexamples. The use of induction enables Salsa to combat the state 
explosion problem that plagues model checkers - it can handle specifica- 
tions whose state spaces are too large for model checkers to analyze. Also, 
unlike general purpose theorem provers. Salsa concentrates on a single 
task and gains efficiency by employing a set of optimized heuristics. 



1 Introduction 

Model checking [17] has emerged as an effective technique for the automated 
analysis of descriptions of hardware and protocols. To analyze software system 
descriptions, however, a direct application of model checking to a problem (i.e., 
without a prior reduction of its state space size by the application of abstraction) 
rarely succeeds [9]. For such systems, theorem proving affords an interesting al- 
ternative. Conventional theorem proving systems, however, are often too general 
or too expensive to use in a practical setting because they require considerable 
user sophistication, human effort, and system resources. Additionally, the coun- 
terexample provided by a model checker when a check fails serves practitioners 
as a valuable debugging aid. However, in contrast, conventional theorem provers 
provide little or no diagnostic information (or worse, may not terminate) when 
a theorem is not true. 
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Salsa is an invariant checker for system descriptions written in a language 
based on the tabular notation of SCR [24] called SAL (the SCR Abstract 
Language). Given a logical formula and a system description in SAL, Salsa uses 
induction to determine whether the formula is true in all states (or transitions) 
the system may reach. Unlike concurrent algorithms or protocol descriptions, 
on which model checkers are very effective, practical SAL models usually do 
not contain interleaving concurrency and are more easily amenable to induction 
proofs. If a proof fails. Salsa provides a counterexample. Unlike model checkers, 
however, the returned counterexample is a state or a state pair and not an execu- 
tion sequence. Also, due to the incompleteness of induction, users must validate 
a returned counterexample. Salsa has the attributes of both a model checker 
and a theorem prover: It is automatic and provides counterexamples just like a 
model checker. Like a theorem prover, it uses decision procedures, can handle 
infinite state systems, and can use auxiliary lemmas to complete an analysis. 

The design of Salsa was motivated by the need within the SCR Toolset [23] for 
more automation during consistency checking [24] and invariant checking [9,22]. 
Salsa achieves complete automation of proofs by its reliance on decision proce- 
dures, i.e., algorithms that establish the logical truth or falsity of formulae of 
decidable sub-theories, such as the fragment of arithmetic involving only integer 
linear constraints called Presburger arithmetic. Salsa’s invariant checker con- 
sists of a tightly integrated set of decision procedures, each optimized to work 
within a particular domain. Currently, Salsa implements decision procedures for 
propositional logic, the theory of unordered enumerations, and integer linear 
arithmetic. 

Although they are capable of checking more general properties (such as live- 
ness), in practice model checkers are most often used to check invariant proper- 
ties. The advantage of using Salsa over a standard model checker for this task 
is that Salsa can handle large (even infinite state) specifications that current 
day model checkers cannot analyze. This is due to the use of induction and the 
symbolic encoding of expressions involving integers as linear constraints. The 
primary disadvantage of Salsa (and proof by induction in general) is its incom- 
pleteness - a failed check does not necessarily imply that a formula is not an 
invariant because the returned state pair may not be reachable. 

After some experimentation, we arrived at the following practical method 
for checking state and transition invariants using Salsa (see Figure 1): Initially 
apply Salsa. If Salsa returns yes then the property is an invariant of the system, 
and we are done. If Salsa returns no, then we examine the counterexample to 
determine whether the states corresponding to the counterexample are reachable 
in the system. If so, the property is false and we are done. However, if one 
concludes after this analysis that the counterexample states are unreachable, 
then one looks for stronger invariants to prove the property. Salsa currently 
includes a facility that allows users to include such auxiliary lemmas during 
invariant checking. There are promising algorithms for automatically deducing 
such invariants [5,6,11,26], although Salsa currently does not implement them. 
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Fig. 1. Process for applying Salsa 



Related Work. The use of SMV [28] and SPIN [25] on software specifications for 
consistency and invariant checking has been well documented [2,9,16,22]. SCR* 
[23] is a toolset that includes a eonsisteney checker which uses a method based 
on semantic tableaux extended to handle simple constraints over the integers 
and reals. This tool has proved very useful in a number of practical case studies; 
however, the tool is unable to complete the checks on certain examples involving 
numbers. Systems that largely automate induction proofs by employing decision 
procedures include the Stanford Temporal Prover (STeP) [11]. Other tools that 
are built upon the interactive theorem prover PVS [30] include TAME (Timed 
Automata Modeling Environment) [3] and the tools of Graf et al. [21,32]. These 
tools are implemented as a set of special-purpose PVS strategies. The tool In- 
VeSt includes sophisticated algorithms for invariant generation and heuristics for 
invariant strengthening [5,6]. Also, if invariance cannot be established on a finite 
abstraction, an execution sequence is provided as a diagnostic. Validity checkers 
such as Mona [18], Mosel [31], and the Stanford Validity Checker (SVC) [4] are 
another class of systems that employ decision procedures for proving logical for- 
mulae. Although these tools do not directly check invariants, they may be used 
to discharge the verification conditions generated during an induction proof in 
a tool such as Salsa. 

The idea of combining decision procedures for program verification dates 
back to the work of Shostak [33] and Nelson and Oppen [29]. The decision pro- 
cedures of Salsa for both propositional logic and enumerated types are based on 
standard BDD algorithms. The integer constraint solver employs an automata- 
theoretic algorithm presented in [12], with extensions to handle negative numbers 
using ideas from [34] . Salsa’s technique of combining BDD algorithms with con- 
straint solvers was largely inspired by the approaches of [14] and [15] where, 
by incorporating constraint solvers into BDD-based fixpoint computation algo- 
rithms, verification of infinite state systems becomes a possibility. However, since 
the underlying algorithms of these systems are variants of the model checking 
algorithm for computing a fixpoint, we speculate that Salsa, due to its use of in- 
duction, can handle larger specifications than these systems. Also, the constraint 
solver of [14] is incomplete for integer linear arithmetic, whereas the one used by 
Salsa is complete. The system of [15], which uses an off-the-shelf backtracking 
solver that can be very inefficient in practice, can handle a class of non-linear 
constraints in addition to linear constraints. 
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The rest of this paper is organized as follows. In the following section we 
introduce the state machines that serve as the underlying models for SAL speci- 
fications and define the invariant checking problem. Section 3 describes the core 
algorithms of Salsa, and Section 4 presents the algorithms and heuristics of the 
unsatisfiability checker which is used by Salsa to discharge the verification condi- 
tions. Section 5 provides some preliminary experimental results of applying Salsa 
to several practical specifications of moderate size. Finally, Section 6 discusses 
ongoing work and future research. 

2 Background 

2.1 Model for System Behavior 

The SCR Abstract Language (SAL), a specification language based on the SCR 
Formal Model [24], was designed to serve as an abstract interface to analysis 
tools such as theorem provers, model checkers, and consistency checkers. An 
example SCR specification in SAL is presented in Appendix A. Unlike concur- 
rent algorithms or protocol descriptions, practical SAL specifications usually do 
not involve interleaving concurrency and are therefore more easily amenable to 
induction proofs. 

A SAL specification may be translated into a state machine that models a 
system’s behavior. We now introduce the state machine model for systems and 
the supporting machinery used in the paper. We define formulae in a simple 
constraint logic (SCL) by the following grammar: 

<P := C I Xb I ~^Xb I ^ V ^ I /\<P (simple formulae) 

C := Ci I Ce (constraints) 

Ce '■= Xe = Valf, I Xe ^ V ale \ Xe = Ye \ Xe ^ Ye (cnum. Constraints) 

Ci := SUM < Vali \ SUM=VaU \ SUM^Vah (integer constraints) 

SUM := Vali x | SUM+ SUM 

where Xb, XejYe, and Xi range over boolean, enumerated, and integer variables 
respectively. Similarly V alb, Vale, and Vali respectively range over constants of 
the three types. We let Vars{(P) denote the free variables in (p. Set Vars{<P) 
is partitioned by the three variable types: Vars{(P) = Varsb{'P) U VarSei'P) U 
Varsi{<P). Note that SCL formulae will be interpreted in the context of either 1) 
a single state s that maps variable names to values or 2) a pair of states (s, s'), 
where s' is a successor of s. We adopt the convention that primed formulae and 
variable names (those ending in ') are evaluated in the “new state” whereas 
unprimed names are evaluated in the “old state.” Formulae containing primed 
variables are called two-state predicates and those without primed variables are 
called one-state predicates. 

Definition 1. A state machine A is a quadruple {V,S,6,p) where 

— V is a set of variable names. This set is partitioned into monitored variables 
which denote environmental quantities the system observes; controlled vari- 
ables which denote quantities in the environment that the system controls; 
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and internal variables which are updated by the system but not visible to 
the environment. 

— S is the set of system states such that each state s G S maps each x gV to 
a value in its set of legal values. We write a;(s) to mean the value of variable 
X in state s, '^i(s) to mean the value of one-state predicate <Pi evaluated 
in s, and ^ 2 (s,s') to mean the value of two-state predicate ^2 evaluated 
with values from s replacing unprimed variables and values from s' replacing 
primed variables. 

— 0 is a one-state SCL predicate defining the set of initial states. 

— p is a two-state SCL predicate defining the transitions (execution steps) of 
S. A state s may evolve to a state s' if p(s, s') is true. 

The transition relation p additionally includes environmental assumptions 
as well as assumptions introduced by users. For details, see [10]. 



2.2 The Invariant Checking Problem 

Definition 2. Given a state machine E = (V, S, 0, p), a state s € 5 is reachable 
(denoted Reachable s{s)) if and only if 9{s) or 3s2 G S : Reachable s{s 2 )/\p{s 2 , s) 

Definition 3. Given a state machine E = (V, S, 9,p), a one-state SCL predicate 
is a state invariant of E if and only if 

t/s G S : Reachables(s) ^ ^^i(s) 

A two-state SCL predicate <^2 is a transition invariant of E if and only if 
Vs, s' G S : {Reachable s{s) A p(s, s')) ^ 2 ( 3 , s') 

The invariant checking problem : Given a state machine E and a one(two)-state 
predicate determine whether ^ is a state(transition) invariant. 



3 The Invariant Checker 

Theorem 1. Let E = (V, S, 9, p), then <l>i is a state invariant of E if the follow- 
ing hold: 1) \/s G S : 9{s) '^i(s) and 2) Vs, s' G 5 : <?i(s) A p(s, s') ^ ^i(sO 

Proof: By induction on the number of steps of E to reach a state. 

Theorem 2. Let E = (V,S,9,p), then ^2 is a transition invariant of E if the 
following holds: 

Vs, s' G S ■. p{s, s') => ^ 2 (s, s') 



Proof: Follows directly from Definition 3. 
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3.1 The Invariant Checking Algorithms 

Using Theorems 1 and 2 we check invariants oi E = (V, 5, 0, p) as follows: 

State Invariants. To determine if is a state invariant of E-. 

0. if is unsatisfiable then return yes. 

1. if 0 A is not unsatisfiable then return no and the satisfying state as 
counterexample . 

2. if A p A is unsatisfiable then return yes. 

else return no and the satisfying state pair as counterexample. 

Transition Invariants. To determine if <p 2 is a transition invariant of E: 

0. if is unsatisfiable then return yes. 

1. if p A ^^2 is unsatisfiable then return yes. 

else return no and the satisfying state pair as counterexample. 

These algorithms are sound but not complete - whenever Salsa returns yes 
the given formula is an invariant; however, a no answer with a counterexample (a 
state or a state pair) does not necessarily mean that the formula is not an invari- 
ant. Consequently, the user must validate that the counterexample is reachable^. 
Either there is a problem or additional theorems are used to “push through” the 
invariant. Of course, all added theorems should be proved as invariants by the 
user (either with Salsa or by some other means) . 

3.2 Optimizations 

A naive application of the above algorithms to invariant checking will always 
fail, even for specifications of a moderate size. We perform several optimizations 
in Salsa to make invariant checking feasible. One important technique used ex- 
tensively is to cache results as they are computed. In addition to the caching 
provided by BDD algorithms, we cache the results of calls to the integer con- 
straint solver, the BDD encodings of components of the transition relation, etc. 

To partition an unsatisfiability check into simpler sub-problems, we use a 
technique called disjunctive partitioning which corresponds to a case split in a 
standard proof. This approach takes advantage of the fact that a disjunction is 
unsatisfiable only if each of its disjuncts is unsatisfiable. The disjunctive form of 
the transition relation in SAL specifications has proven to be an effective basis 
for disjunctive partitioning. 

The application of abstraction [9,22] is also very beneficial. We restrict our- 
selves to applying abstractions that are both sound and complete, by which we 
mean the following. Given a property <P and a state machine E, an abstraction 
Ea is a sound and complete abstraction of E relative to d> when <1> is an invariant 
of Ea if and only if is an invariant of E. Currently, we apply what is termed 
“Abstraction Method F [8,9] that uses the set of variable names occurring in the 
predicate and dataflow analysis to eliminate unneeded variables. 

^ The single state counterexample returned by step 1 of the algorithm for State Invari- 
ants (for a failed check of unsatisfiability of 0A^^i) is always a true counterexample. 
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4 The Unsatisfiability Checker 

4.1 Overview 

To discharge the verification conditions that arise during invariant checking, 
Salsa uses a routine that decides the unsatisfiability of SCL formulae. Both the 
problem of propositional unsatisfiability and the decision problem for integer 
linear arithmetic are NP-complete [20], and known algorithms for the latter 
problem have super-exponential worst case behavior [19]. The unsatisfiability 
checker uses a combination of binary decision diagrams and an integer constraint 
solver as a decision procedure for SCL formulae. Using the formula a; < 4Ax = 7 
as an example we outline the algorithm (for specifics, see [10]). The initial step 
transforms a formula into one containing only logical connectives and boolean 
variables. This is done by assigning a fresh boolean variable to each integer 
constraint in the original formula. Fresh boolean variables are also introduced 
to encode expressions involving variables of enumerated type in the obvious 
way [10,28]. For the example, substituting a for x < 4 and b for x = 7 yields the 
formula a A b. Next, a BDD for this formula (which encodes the propositional 
structure of the original formula) is constructed: 



The next step brings in the information contained in the integer constraints. 
This is done by searching for paths from the root to “True” , each path yielding a 
set of integer constraints. For the example, the only path from the root to “True” 
sets both a and b to true, which yields the set {a;<4, x = 7}. The final step 
is to determine whether each such set is infeasible (i.e., has no solution) using 
an integer constraint solver. If a set is feasible, this information is returned to 
the user as a counterexample. For the example, the (single) set of constraints is 
infeasible and the formula is unsatisfiable. We now describe the integer constraint 
solver in detail. 

4.2 The Integer Constraint Solver 

As an initial step, a set of integer constraints is partitioned into independent 
subsets. For example, the set of constraints {x < 4, x > 7, y < 10} may be 
partitioned into {a; < 4,a; > 7} and {y < 10}. 



a 




b 




False 



True 



Definition 4. Constraints ci and C 2 are independent if Vars{ci)r\Vars{c 2 ) = 0 . 
The partition of a set of constraints CS = {ci, ...,c„} into independent subsets 
(denoted II{CS)) is defined as II{CS) = {CS”!, ...,CSm} such that: 



Salsa: Combining Constraint Solvers with BDDs 



385 



1. n{CS) partitions CS. 

2. Constraints in different partitions are independent. 

3. For each partition containing more than one constraint, every constraint in 

the partition depends on some other constraint in the partition. 

To compute II {CS) Salsa uses a union-find algorithm that starts with each con- 
straint in its own partition and iteratively merges partitions when they contain 
dependent constraints. 

After partitioning a set of constraints into independent subsets, an integer 
constraint solver determines the feasibility of each independent subset. For a set 
of constraints, we may conclude that the whole set is infeasible if any independent 
subset is infeasible. 

Salsa’s constraint solver is a decision procedure that determines whether a 
set of integer constraints is infeasible, i.e., given {ci,C 2 , ■■■^Cn} the solver checks 
whether CiAc 2 A...Ac„ is unsatisfiable. Note that the Ci are terms from the integer 
constraint fragment of SCL (defined in Section 2.1). Among several methods 
available for solving linear integer constraints, one possible approach is the use 
of automata theoretic methods. The idea, which dates back to Biichi in the 
early sixties [13], is to associate with each constraint an automaton accepting 
the solutions of the constraint. The feasibility of a set of constraints may then be 
computed by constructing a composite automaton (from the constraint automata 
for each Cj, 1 < i < n) using the standard construction for automata intersection. 
Salsa’s solver employs the algorithm of Boudet and Comon [12], extended to 
handle negative number based on ideas of Wolper [34]. We give an overview of 
the algorithm, for details see the above references. 

Let us first examine how a constraint automaton may encode constraints 
over the natural numbers, and then extend this idea to automata for inte- 
ger constraints. Let c be a constraint, let Vars{c) = {xi, X2, ■■■, Xn}, and let 
c[yi/xi,y2/x2, ■■■,yn/xn] denote the result of substituting yi for each Xi in c. 
We then define the constraint automaton for c, denoted CAut(c), such that the 
language of CAut(c) is {(yi, ..., ?/„) € InC \ c[yi/a;i, ..., y„/a;„] is true}. Each 
number yi is encoded in base two, so each yi is a string in {0, 1}*. The constraint 
automaton will recognize solutions to a constraint by simultaneously reading one 
bit for each of its free variables, i.e., the edges of the automaton will be labeled 
by elements of {0, 1}". For example, the satisfying assignments of “xi + X 2 = 4” 
are {(0, 4), (1, 3), (2, 2), (3, 1), (4, 0)}, so CAut(xi-|-X 2 = 4) encodes this as shown 
in Figure 2. 

We now explain how to construct a constraint automaton for a constraint c 
of the form a\Xi + 02 X 2 -f . . . + anXn = b, where 01 , 02 , . . . o„, b are integer 
constants and xi,X 2 , ■ ■ ■ Xn are variables over the natural numbers. The resulting 
automaton will be of the form CAut(c) = (S, E, St, Acc) where S C Integers is 
the set of states and if C S' x {0, 1}" x S is the set of edges, St C S is the set 
of start states, and Acc C S is the set of accepting states. During construction 
we let Snew represent the set of states still to be processed. The construction 
proceeds backwards from the accepting state as follows. 
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{xi,X2} 


Accepted string 


(0.4) 


0 0 0 
1 0 0 


(1.3) 


0 1 
1 1 


(2.2) 


1 0 
1 0 


(3.1) 


1 1 
0 1 


(4.0) 


1 0 0 
0 0 0 




Fig. 2. The constraint automaton encoding xi + 3:2 = 4 

1 . Initialize both Snew and Acc to contain only b (the right hand side of the constraint) 

and initialize S — E — St = ^. 

2. Remove a state s from Snew for processing. 

(a) Add s to S. If s = 0 then also add s to St. 

(b) For each /3 G {0, 1}" where j3 = (&i, 62 , bn) 
let (5 = s — (aibi + a 2&2 + • • • + anbn) in 

if S is even then 

• add edge (S div 2) s to F 

• if (5 div 2) ^ (5 U Snew) then add (5 div 2) to Snew 

3. if Snew = 0 then return {S, E, St, Acc) else goto 2. 

Some simple modifications to the above algorithm extend it to handle nega- 
tive numbers. For integer constraint c, the states of CAut(c) range over integers 
and we add a special state I that will encode the start state, thus S C IntUX. 
Instead of the standard binary encoding employed for natural numbers the two’s 
complement representation is used for integers. The above algorithm must also 
be modified to handle the sign bit of the two’s complement notation via a special 
encoding for the start state (X) and extra edges from X. We do this by removing 
“if s = 0 then also add s to SE from 2 (a) and adding the following to 2 (b) 
above. 

if S = ( — ai&l — 02^2 — . . . — Cnbn) 

then add X to 5 and St and add edge X s to E. 

The basic algorithm may also be changed to build constraint automata for 
constraints involving and “<”. For “y^” the construction is exactly the 
same except that Acc = S — b, i.e., the accepting state becomes non-accepting 
and all others become accepting. For details of the slightly more complicated 
modifications for “<” see [10]. 

The constraint automaton for a set of constraints CS = {ci, C 2 , ..., Cn}, de- 
noted CAut(C5'), is defined as CAut(C5') = nr=i The automaton 

CAut(CS') is constructed on the fly, thereby avoiding the need to build each 
CAut(ci). Let Si denote the states of CAut(ci), then the states of CAut(C'5') 
are Scs E Si x S 2 x Sn- An unsatisfiability check of CS then proceeds 
backwards from the accepting state and terminates with false when the initial 
state is reached or terminates with true if the automaton construction completes 
without reaching the start state. 
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5 Empirical Results 

5.1 Motivation 

Salsa was designed expressly for the problems of consistency checking and invari- 
ant checking SCR requirements specifications. More specifically, the consistency 
checker of the SCR Toolset [23] was unable to carry out certain checks, such 
as checks for unwanted nondeterminism called disjointness checks, especially on 
specifications containing expressions with numbers. We have also been using 
SPIN and SMV, and more recently TAME [3] , to verify user formulated proper- 
ties of SCR specifications. We compare Salsa with TAME/PVS to gain an insight 
into how well the Salsa approach performs in relation to that of a state-of-the-art 
theorem prover. 

We compare Salsa with model checkers for the following reason. During the 
course of our experiments with SCR specifications we have discovered that for 
model checking to succeed on these specifications requires the application of 
abstraction, which currently requires user-direction but is automatable [9,22]. 
Further, SPIN and SMV are unable to provide a definitive answer for invariant 
checks on a number of examples, especially when they contain a large number of 
expressions with numbers [27]. Also, since several researchers are currently inves- 
tigating the use of SPIN and SMV for invariant checking software specifications, 
it is our intention to demonstrate that Salsa affords a viable, perhaps more auto- 
mated and cheaper, alternative to model checking. Whereas mechanical theorem 
provers are regarded as being difficult to use and therefore restricted to sophis- 
ticated users, model checking too is often misrepresented as fully automatic or 
“push button” . Our intention is to demonstrate an approach to invariant check- 
ing that avoids both the ad hoc abstraction used in model checking and the 
sophistication required to apply mechanical theorem proving. 

The specifications we use in our experiments were developed using the SCR 
Toolset. Since Salsa seems to work well on all of this limited set of examples, 
readers may express skepticism about the generality of our results - they may 
feel that there must be benchmarks for which the roles would be reversed. By us- 
ing induction, abstract encodings for linear constraints, and application-specific 
heuristics, our experience is that the Salsa approach can in general be more 
efficient than fixpoint computation over a finite domain, i.e., model checking. 
However, Salsa has the disadvantage of not working in all cases, due to the 
associated problem of incompleteness. 

Test Cases. These include a simplified specification of the control software for a 
nuclear power plant [24] (safety-injection), versions of the bomb-release com- 
ponent of the flight-control software of an attack aircraft [1] (bomb-release- 1 
and bomb-release-2), a simplified mode control panel for the Boeing 737 au- 
topilot [7] (autopilot), a control system for home heating (home- heating), 
an automobile cruise control system (cruise-control), a navy application [27] 
(navy), the mode logic for the Operational Flight Program of an attack air- 
craft [1] (a7-modes), and a weapons control panel [22] (wcp). 
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5.2 Disjointness Checking 



To evaluate the performance of Salsa, we checked the above specifications for 
disjointness errors (unwanted nondeterminism) and compared the results with 
the consistency checker of the SCR Toolset. The results of our experiments 
are shown in the table of Figure 3. No auxiliary lemmas were used for 
any of the checks. The column labeled “number of verification conditions” 
indicates how many invariant checks are required to establish disjointness for the 
corresponding entire specification. The number of BDD variables is an indicator 
of a specification’s size, and the number of integer constraints correlates loosely 
with the degree to which integers are used in the specification. In these tables, 
symbol “oot” means that the corresponding system either ran out of memory or 
failed to terminate (over a weekend). The column labeled “number of failed VCs” 
shows the number of verification conditions that were not provable. Note: for 
the specification a7-modes Salsa reports more failed VCs than the SCR toolset 
because certain cases of overlap in table entries are misdiagnosed as disjointness 
errors when they should probably be warnings. For specification cruise-control 
Salsa establishes disjointness in three cases for which the SCR Toolset cannot. 
The tests were conducted on a PC running Linux with a 450 MHz Pentium II 
processor and 256 MBytes RAM. 



Specification 


Number of 


Time (in seconds) 
to Check Disjointness 


Number of 
Failed VCs 


Verifieation 

Conditions 


BDD 

Variables 


Constraints 


SCR 

Toolset 


Salsa 


SCR 

Toolset 


Salsa 



Specifications containing mostly booleans and enumerated types 



safety- injection 


13 


16 


3 


0.5 


0.2 


0 


0 


bomb-release- 1 


12 


34 


9 


0.4 


0.2 


0 


0 


a7-modes 


6171 


158 


3 


145.9 


68.9 


110 


152 



Speeifieations containing mostly numerical variables 



home-heating 


98 


112 


55 


OOt 


4.8 


n.a. 


0 


cruise-control 


123 


114 


75 


21.0 


3.6 


6 


3 


navy 


397 


147 


102 


390.1 


198.2 


0 


0 


bomb-release-2 


339 


319 


230 


OOt 


246.0 


n.a. 


11 



Fig. 3. Results of Disjointness Checks 



Figure 3 shows that for specifications containing mostly variables of boolean 
and enumerated type, both the SCR Toolset and Salsa can complete the analysis 
but Salsa is somewhat faster. For specifications containing mostly numerical 
variables, there were two specifications in which Salsa could perform the analysis 
but the SCR Toolset could not. 
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5.3 Checking Application Properties 

To evaluate Salsa’s performance on properties formulated by users, we com- 
pared the run times with the theorem prover TAME/PVS and the two popular 
model checkers SPIN [25] and SMV [28]. (We used SPIN Version 2.9.7 of April 
18, 1997, SMV i'2.4 of December 16, 1994, and PVS version 2.1 for our exper- 
iments.) The results are shown in Figure 4. Note that the PVS proof times do 
not include time for type checking, which can be substantial. We ran the ex- 
periments on a SPARC Ultra-2 running Solaris with a 296 MHz UltraSparc II 
processor and 262 MBytes RAM. All Salsa proofs were completely automatic, 
but for property 304 of wcp, which had to be split into two verification condi- 
tions for Salsa to complete; the time indicated with an asterisk is the sum of the 
running times of the two sub-proofs. All auxiliary lemmas were automat- 
ically generated by the algorithm of [26] and proved as invariants by Salsa. 
Both SPIN and SMV ran out of memory (or ran indefinitely) when run on all 
examples other than safety-injection. This is probably because they contain a 
large number of numerical variables. Dashes (“-”) in the SMV column indicate 
that we did not run SMV on these examples. 



Specification 


Number of 
Properties 


Time (in seconds) 


Properties 

Proved? 


Auxiliary 

Lemmas 

Used? 


Salsa 


SPIN 


SMV 


TAME/PVS 


safety- injection 


4 


0.8 


36.0 


155.0 


68 


Yes 


Yes 


bomb-release- 1 


2 


1.3 


OOt 


OOt 


30 


Yes 


No 


autopilot 


2 


1.5 


OOt 


OOt 


82 


Yes 


No 


navy 


7 


396.0 


OOt 


- 


874 


Yes 


Yes 


wcp 


property 303 


295.4 


OOt 


- 


OOt 


No 


No 




property 304 


923.3* 


OOt 


- 


19 


No 


No 




property 305 


2.4 


OOt 


- 


8 


No 


No 



Fig. 4. Results of Invariant Checks 



6 Conclusions 

In this paper, we show that the Salsa approach affords a useful alternative to 
model checking, especially for the analysis of descriptions of software. Mechan- 
ical theorem provers such as PVS are regarded as being too general and too 
expensive to use, requiring sophistication on the part of their users. Salsa pro- 
vides the advantages of both mechanical theorem proving and model checking 
- it is automatic, easy to use, and provides counterexamples along the lines of 
model checkers. The counterexamples, however, are over two adjacent states and 
not entire execution sequences. The main advantage of our approach is that we 
are able to handle much larger specifications, even infinite state specifications, 
that current day model checkers cannot handle (without a prior application of 
abstraction) . 
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The major disadvantage of the Salsa approach over conventional model check- 
ing is its incompleteness - a proof failure does not imply that the theorem does 
not hold. However, this is generally true of model checking too, because an initial 
application of model checking to a practical problem rarely succeeds - users of 
model checkers routinely apply abstractions (mostly manually and sometimes in 
ad-hoc ways) for model checking to proceed [9]. These abstractions are usually 
sound, but are often incomplete - consequently, if one model checks an incom- 
plete abstraction of a problem, the entire process is incomplete. Model checking, 
however, remains very useful for refuting properties, i.e., as a debugging aid. 
As with Salsa, the resulting counterexample must be validated against the full 
specification. 

We plan to extend Salsa to include decision procedures for the rationale, the 
congruence closure algorithm to reason about uninterpreted function symbols, 
and special-purpose theories such as for arrays and lists. We would also like to 
reason about quantifiers. We have designed Salsa to be general, i.e., to check a 
variety of state machine models for invariant properties. We plan on trying out 
the tool on state machine models other than SCR. 
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A SAL Specification of Safety Injection System 

A module is the unit of specification in SAL and comprises variable declarations, 
assumptions and guarantees, and definitions. The assumptions section typically 
includes assumptions about the environment and previously proved invariants 
(lemmas). The required invariants of a module are specified in the guarantees 
section. The definitions section specifies updates to internal and controlled 
variables. A one-state definition, of the form var x = rhsl (where rhs\ is a 
one-state SAL expression) , defines the value of variable x in terms of the values 
of other variables in the same state. A two-state variable definition, of the form 
var X initially init := rhs2 (where rhs2 is a two-state SAL expression), 
requires the initial value of x to equal expression init] the value of x in the “new” 
state of each state transition is defined in terms of the values of variables in the 
“new” state as well as the “old” state. Expression @T(x) WHEN y is syntactic 
sugar for ^x A x' A y and @F(x) denotes @T(N0T x). A conditional expression 
consists of a sequence of branches “ [] guard ^ expression” , where the guards 
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are boolean expressions, bracketed by the keywords “if” and “fi”. In a given 
state, the value of a guarded expression is equivalent to the expression on the 
right hand side of the arrow whose associated guard is true. If more than one 
guard is true, the expression is nondeterministic. A conditional event expression 
(which is bracketed by the keywords “ev” and “ve”) requires each guard to 
denote an event, where an event is a two-state expression that is true in a pair 
of states only if they differ in the value of at least one state variable. 

We specify in SAL a simplified version of a control system for safety injec- 
tion [9]. The system monitors water pressure and injects coolant into the reactor 
core when the pressure falls below a threshold. The system operator may over- 
ride safety injection by pressing a “Block” button and may reset the system by 
pressing a “Reset” button. To specify the requirements of the control system, we 
use variables WaterPres, Block, and Reset to denote the monitored quantities 
and variable Safetyinjection to denote the controlled quantity. The specifica- 
tion includes a mode class Pressure, an abstract model of WaterPres, which has 
three modes: TooLow, Permitted, and High. It also includes a term Overridden 
and several conditions and events. 
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module sis 
functions 

Low = 900; Permit = 1000; 
monitored variables 

Block, Reset : {On, Off}; 

WaterPres : int in [0,2000] ; 
controlled variables 

Safetyinjection : {On, Off}; 
internal variables 
Overridden : bool ; 

Pressure : {TooLow, Permitted, High}; 
assumptions 

/* Mode invariant generated by the algorithm of Jeffords [26] */ 

LemmaZ = (Overridden => Reset = Off and not (Pressure = High) ) ; 
guarantees 

/* The following properties are true */ 

Propertyl = (Reset = On and Pressure != High) => not Overridden; 
Property2 = (Reset = On and Pressure = TooLow) => Safetyinjection = On; 
/* The following properties are false */ 

PropertyS =(Block = Off and Pressure = TooLow) => Safetyinjection = On; 
Property4 =(@T(Pressure=TooLow) when Block=0ff) => SafetyInjection’=0n; 

definitions 

var Overridden initially false := 
ev 

[] @T(Pressure = High) -> false 

[] @T(Block = On) when (Reset = Off and Pressure != High) -> true 
[] @T (Pressure != High) or 

@T(Reset = On) when (Pressure != High) -> false 
ve 
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var Pressure initially TooLow := 
case Pressure 

[] TooLow -> ev [] @T(WaterPres >= Low) -> Permitted ve 

[] Permitted -> ev [] @T(WaterPres < Low) -> TooLow 

[] @T(WaterPres >= Permit) -> High 
ve 

[] High -> ev [] @T(WaterPres < Permit) -> Permitted ve 

esac 

var Safetyinj action = 
case Pressure 

[] High, Permitted -> if [] true -> Off [] false -> On fi 

[] TooLow -> if [] Overridden -> Off [] not Overridden -> On fi 

esac 

end module 

Fig. 5. SAL specification of Safety Injection System 
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Abstract. This paper reports on experimental results with symbolic 
model checking of probabilistic processes based on Multi- Terminal Bi- 
nary Decision Diagrams (MTBDDs). We consider concurrent probabilis- 
tic systems as models; these allow nondeterministic choice between prob- 
ability distributions and are particularly well suited to modelling dis- 
tributed systems with probabilistic behaviour, e.g. randomized consen- 
sus algorithms and probabilistic failures. As a specification formalism we 
use the probabilistic branching-time temporal logic PBTL which allows 
one to express properties such as “under any scheduling of nondeter- 
ministic choices, the probability of <j) holding until i/) is true is at least 
0.78/at most 0.04" ■ We adapt the Kronecker representation of (Plateau 
1985), which yields a very compact MTBDD encoding of the system. 
We implement an experimental model checker using the CUDD package 
and demonstrate that model construction and reachability-based model 
checking is possible in a matter of seconds for certain classes of systems 
consisting of up to 10®° states. 



1 Introduction 

There have been many advances in the BDD technology since BDDs were first 
introduced and applied to symbolic model checking [10,25]. There are several 
free and commercial BDD packages in existence, as well as a range of alternative 
techniques for efficient automatic verification. Model checking tools (to mention 
smv, SPIN, fdr2) are extensively used by industrial companies in the process of 
developing new designs for e.g. hardware circuits, network protocols, etc. More 
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recently tremendous progress has been made with tools for the model checking 
of real-time systems, e.g. Uppaal [6]. 

One area that is lagging behind as far as experimental work is concerned, de- 
spite the fact that the fundamental verification algorithms have been known for 
over a decade [32,15,28], is model checking of probabilistic systems. This is partic- 
ularly unsatisfactory since many systems currently being designed would benefit 
from probabilistic analysis performed in addition to the conventional, qualita- 
tive checks involving temporal logic formulas or reachability analysis available in 
established model checking tools. This includes not only quality of service prop- 
erties such as “with probability 0.9 or greater, the system will respond to the 
request within time t” , but also steady-state probability (until recently, see [17,4] , 
separate from temporal logic model checking), which allows the computation of 
characteristics such as long-run average, resource utilization, etc. 

In order to support efficient verification of probabilistic systems, BDD-based 
packages must allow a compact representation for sparse probability matrices. 
Such a representation, Multi-Terminal Binary Decision Diagrams (MTBDDs), 
was proposed in [14] along with some matrix algorithms. MTBDDs are also 
known as Algebraic Decision Diagrams (ADDs) [1] and are implemented in the 
Colorado University Decision Diagram (CUDD) package of Fabio Somenzi [31]. 
Based on [22], an MTBDD-based symbolic model checking procedure for purely 
probabilistic processes (state-labelled discrete Markov chains) for the logic PCTL 
of [22] (a probabilistic variant of CTL) was first presented in [3], and since ex- 
tended to concurrent probabilistic systems in [2] (without implementation) . Sim- 
ilarly, a symbolic model checking procedure for continuous time Markov chains 
is proposed in [4] . An alternative representation for Markov chains called Proba- 
bilistic Decision Graphs (PDGs) was introduced in [9], where early experimental 
results are also reported. 

In this paper we consider concurrent probabilistic systems [5], based on 
Markov Decision Processes [7], similar to those of [32,8]. These are state-labelled 
systems which admit nondeterministic choice between discrete probability dis- 
tributions on the successor states, and are particularly appropriate for the repre- 
sentation of randomized distributed algorithms, fault-tolerant and self-stabilising 
systems. The model checking procedure, first proposed in [15,8] for the case with- 
out fairness and extended to incorporate fairness constraints in [5,18], reduces 
to the computation of the minimum/maximum reachability probability. We can 
derive a set of linear inequalities, and maximize/minimize the sum of the compo- 
nents of the solution vector subject to the constraints given by the inequalities. 

Multi-Terminal Binary Decision Diagrams [14] have the same structure as 
BDDs, except that terminals other than 0 and 1 are allowed. The similarity 
between the two types of diagrams means that many BDD operations gener- 
alise to the MTBDD case. MTBDDs are known to yield a compact and efficient 
representation for sparse matrices [14]. They share many positive features with 
BDDs: because they exploit regularity and sharing, they allow the representation 
of much larger matrices than standard sparse matrix representations. MTBDDs 
also combine well with BDDs in a shared environment, thus allowing reaeha- 
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bility analysis via conversion to BDDs (which coincide with 0-1 MTBDDs) and 
conventional BDD reachability. However, MTBDDs also inherit negative BDD 
features: they are exponential in the worst case, very sensitive to variable order- 
ing heuristics, and may be subject to a sudden, unpredictable, increase in size as 
the regularity of the structure is lost through performing operations on it. As a 
consequence, algorithms that change the structure of the matrix, such as Gaus- 
sian elimination for solving linear equations [1] or simplex for solving systems of 
linear inequalities [24] , are significantly less efficient than state-of-the-art sparse 
matrix packages due to the loss of regularity. Iterative methods [21,23], on the 
other hand, which rely on matrix- by- vector multiplication without changing the 
matrix structure, perform better. 

There has been very little work concerning MTBDD-based numerical lin- 
ear algebra; a notable exception is the CUDD package [31], a free library of C 
routines which supports matrix multiplication in a shared BDD and MTBDD 
environment. In contrast, numerical analysis of Markov chains based on sparse 
matrices is much more advanced, particularly in the context of Stochastic Petri 
Nets. There, with the help of a Kronecker representation originally introduced 
by Brigitte Plateau [26], systems with millions of states can be analysed. The 
Kronecker representation applies to systems composed of parallel components; 
each component is represented as a set of (comparatively small) matrices, with 
the matrix of the full system defined as the reachable subspace of a Kronecker- 
algebraic expression (usually referred to as the actual, versus the potential, state 
space). Then one can avoid having to store the full size matrix by storing the 
component matrices instead and reformulating steady-state probability calcula- 
tion in terms of the component matrices. Existing implementation work in this 
area includes tools such as SMART [11] and PEPS [27]. 

In this paper we adapt and extend the ideas of [3,2] in order to represent 
concurrent probabilistic systems in terms of MTBDDs. The differences with the 
corresponding work in numerical analysis of Markov chains are: we allow non- 
determinism as well as probability; we work with probability matrices, not gen- 
erator matrices of continuous time Markov chains; we generate the matrix in 
full, then perform BDD reachability analysis to obtain the actual state space; 
and we perform model checking against PBTL through a combination of reach- 
ability analysis and numerical approximation instead of steady-state probability 
calculation. The main contribution of the paper is threefold: (1) we implement 
an experimental symbolic model checker for PBTL [5] using MTBDDs; (2) we 
adapt the Kronecker representation of [26] and provide a translation into MTB- 
DDs; and (3) we improve the model checking algorithm by incorporating the 
probability-1 precomputation step of [19]. 

2 Concurrent Probabilistic Systems 

In this section, we briefly summarise our underlying model for concurrent prob- 
abilistic systems; the reader is referred to [5,2] for more details. Our model is 
based on “Markov decision processes”, and is similar to “Concurrent Markov 
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Chains” of [32,16] and “simple deterministic automata” of [29]. Some familiarity 
with Markov chains and probability theory is assumed. 

Concurrent probabilistic systems generalise ordinary Markov chains in that 
they allow a nondeterministic choice between possibly several probability dis- 
tributions in a given state. Formally, a concurrent probabilistic system is a pair 
S = (S', Steps) where S is a finite set of states and Steps a function which as- 
signs to each state s G S a, finite, non-empty set Steps(s) of distributions on S. 
Elements of Steps{s) are called transitions. Systems S = {S, Steps) such that 
Steps(s) is a singleton set for each s G S are called purely probabilistic and 
coincide with discrete time Markov chains. 

Paths in a concurrent probabilistic system arise by resolving both the non- 
deterministic and probabilistic choices. A path of the system S = (S', Steps) is a 
non-empty finite or infinite sequence tt = sq si S 2 • ■ ■ where Si G S, 
Pi G Steps(si) with pi{si+i) > 0. We let 7r(i) denote the ith state of the path tt. 

The selection of a probability distribution is made by an adversary (also 
known as a scheduler), a function mapping every finite path of the system onto 
one of the distributions in Steps{s) where s is the last state of the path. Note 
we use deterministic adversaries, rather than randomized adversaries as in [8]. 
For an adversary A of a concurrent probabilistic system S = (S', Steps) we 
define Path^i to be the set of infinite paths corresponding to the choices of 
the adversary. In the standard way, we define the measure Prob over infinite 
paths. 

Since we allow nondeterministic choice between probability distributions, we 
may have to impose fairness constraints to ensure that liveness properties can 
be verified. In a distributed environment fairness corresponds to a requirement 
for each each concurrent component to progress whenever possible. Without 
fairness, certain liveness properties may trivially fail to hold in the presence of 
simultaneously enabled transitions of a concurrent component. An adversary is 
called fair if any choice of transitions that becomes enabled infinitely often along 
a computation path is taken infinitely often. The interested reader is referred 
to [5,20] for more information on the subject. 

3 The Logic PBTL 

In this section, based on [5,8], we recall the syntax and semantics of the proba- 
bilistic branching-time temporal logic PBTL. PBTL derives from CTL [13] and 
PCTL [22], borrowing the temporal operator U (“until”) and the path quantifier 
3 from CTL, and the probabilistic operator [■[□A from PCTL. 

Let AP denote a finite set of atomic propositions. A PBTL structure is a 
tuple (5,AP,L) where S = {S, Steps) is a concurrent probabilistic system and 
L : S ^ 2^^ is a labelling function which assigns to each state s G S a set of 
atomic propositions. The syntax of PBTL is: 

4> ::= true \ a \ (j)i A 4>2 \ \ [<pi ^ <p 2 ]^x 

where a is an atomic proposition, A G [0, 1], and □ is either > or >. 
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The branching time quantifier 3 involves quantification over adversaries, 
meaning “there exists an adversary” of a given type. Note that to simplify this 
presentation, we have omitted the “bounded until” , “next state” and “universal 
until” operators which can easily be added. The latter is defined similarly to the 
“existential until” operator included above. For a PBTL formula (j> and set Adv 
of adversaries we define the satisfaction relation s \=Adv 4> inductively as follows: 



s \=Adv true 
^ \^Adv n 
s \=Adv (t^l A (j )2 
S \=Adv ~'4’ 

[(j)i 3U 02]da 



for all 5 € 5 

(X € Zy(s) 

5 S 02 

^ ^Adv 0 

Prob{{n 1 7T e Pathf^i(s) & tt \=Adv 4>i ^ 4>2}) 3 A 
for some adversary A G Adv 



TT \=Adv 4>\ld 4>2 there exists fc > 0 such that 7r(fc) \=Adv <^2 

and for all j = 0, 1, . . . , fc - 1, 7r(j) '^Adv <^i 

We denote satisfaction for all adversaries by |= and satisfaction for all fair 
adversaries by \=fair ■ 



4 PBTL Model Checking 

With the exception of “until” formulas and fairness, model checking for PBTL 
is straightforward, see [8,5]. It proceeds by induction on the parse tree of the 
formula, as in the case of CTL model checking [13]. 

We only consider existential “until” for reasons of space. To establish whether 
s \=Adv [4> '0]da, we calculate the maximum probability: 

pT^{ 4> Ufj) = snp{pAf^ Ufj)\AG Adv} 

where pf{(j) U if) = Prob{{TT \ tt € Path^i(s) & tt \= cf U ijj}) and compare 
the result to the threshold A, i.e. establish the inequality □ A. First we 
introduce an operator on sets of states which will be used in the algorithm. 

For Uq,Ui C S, define reachE{Uo,Ui) = pZ[H] as the least fixed point of 
the map iL : 2‘® — > 2'^, where: 

p[ = Ax.(((xGUo) a 3p€ Steps(x) 3y(p(y) > 0 A yGZ)) V (xGUi)). 

The algorithm is shown in Figure 1. We use e = 10“® as the termination criterion 
for the iteration in step 3. Observe that we compute approximations to the 
actual (minimum/maximum) probabilities from below to within e. Alternatively, 
the values p^^^{(j) U if) can be calculated by reduction to linear optimization 
problems [8,5,2]. 

Fairness assumptions, which are necessary in order to verify liveness prop- 
erties of concurrent probabilistic processes, for example “under any scheduling, 
process P will eventually enter a successful state with probability at least 0.7”, 
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1. Compute the sets of states SatiS), Sat(tb) that satisfy d>, ib. 

2. Let (a) := Sat{^) 

(b) S>° := reachE{Sat((l)),S^'^^) 

(c) S'^°:=S\S>° 

(d) 

3. Set pT"{(t> W ^) = 1 if s e and pT""{ct) W i/i) = 0 if s G 5"°. 

For s G S"^ , calculate U ip) iteratively as the limit, as n 

tends to cx3, of the approximations (a:s,n)neiN, where is.o = 0 
and for n = 1, 2 , . . . 

Xs,n = max < Y. r{t) ■ xt,n-i + Y ’'(^) I ^ ^ Steps{s) > . 

[tes? tesy^^ j 

4. Finally, let Sat{[<P EU ip]ux) := {s G S | U ip) ^ A}. 



Fig. 1. The Algorithm EU 

can also be handled. This is possible via reduction of the model checking for 
\=fair to that for ordinary satisfaction \= using results from [5,2]. 

For purely probabilistic systems, model checking of “until” reduces to a linear 
equation system in [S’ ] unknowns which can be solved either through a direct 
method such as Gaussian elimination, or iteratively via e.g. Jacobi or Gauss- 
Seidel iteration. 

4.1 Probability- 1 Precomputation Step 

The model checking algorithm for “until” properties given below can be improved 
by pre-computing the set of all states from which the formula holds with maximal 
probability 1. The algorithm for this precomputation step is based on results 
of [15,16] and can be derived from that in [19] for computing the set of states 
that can reach a goal with probability 1. We have here adapted it to “until” 
formulas. 

For any Zq,Zi C S let Pre{Zo, Zi) be the set of states defined by: 
Pre{Zo,Zi) = 

{x\3p€ Steps{x){\/y{p{y) > 0 ^ y G Zq) A 3y{p{y) > 0 A ?/ G Zi))}. 

Intuitively, s G Pre{Zo, Z\) if one can go from s to Zi with positive probability 
without leaving Zq. 

Theorem 1. Let S = (S', Steps) be a concurrent probabilistic transition system, 
Uo,Ui C S subsets of states and problE(Uo,Ui) be the set of states given by the 
solution to vZqpZiIG] where 



G = \x.{{x G Ui) V {{x G Uq) a X G Pre{Zo, Zi))). 
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Then s€problE{Uo,Ui) if and only if from s, for some adversary, one reaehes 
a state in U\ via a path through states in Uq with probability 1. 

It follows from this theorem that we can strengthen the assignment to 
at step 2(a) of Algorithm EU to: 5^®® := problE{Sat{cf)), Sat{'ip)). Hence, in 
cases of qualitative properties, i.e. properties which are required to hold with 
probability 1, no further computation of the probability vector will be required. 
In particular, this avoids potential difficulties with approximations. 

4.2 Symbolic Model Checking 

A symbolic method is obtained from the above procedure by representing the 
system and probability vector as MTBDDs, Sat{(j>) as a BDD, and expressing the 
probability calculations as MTBDD/BDD operations (for more details see [3,2]). 
The operators reachE{-,-) and problE{-, ■) can be expressed in terms of BDD 
fixed point computation with respect to the transition relation extracted from 
the MTBDD. The iterative calculation of the probability vector requires matrix- 
by- vector multiplication and the operation ABSTRACT(max). 

5 Representing Probabilistic Processes with MTBDDs 

MTBDDs were introduced in [14] as a generalisation of BDDs. Like BDDs, they 
take the form of a rooted directed acyclic graph, the nonterminal nodes of which 
are labelled with Boolean variables from an ordered set. Unlike BDDs however, 
the terminal nodes are labelled with values taken from a finite set D (usually a 
subset of the reals), not just 0 and 1. The operations on MTBDDs are derived 
from their BDD counter-parts, and include Reduce, Apply and Abstract, 
see [1,14]. An MTBDD with n Boolean variables and terminals taken from the 
finite set D, can be considered as a map / : {0,1}” ^ D. 

In [14] it is shown how to represent matrices in terms of MTBDDs. Consider 
a square 2"* x 2’”-matrix A with entries taken from D. Its elements Oy can 
be viewed as the values of a function /a : {1,...,2’”| x {1,...,2'”| ^ D, 
where /a(lj) = o,ij, mapping the position indices i,j to the matrix element Oy . 
Using the standard encoding c : {0, 1}"* — > {1,...,2'”| of Boolean sequences 
of length m into the integers, this function may be interpreted as a Boolean 
function / : {0,1}^'” ^ D where f{x,y) = f a{c{x) , c{y)) for x = {xi,...,Xm) 
and y = (j/i, . . . , j/m)- We require the variables for the rows and columns to 
alternate, that is, use the MTBDD obtained from f{xi,yi,X 2 ,y 2 ,---,Xm,ym)- 
This convention imposes a recursive structure on the matrix from which efficient 
recursive algorithms for all standard matrix operations are derived [1,14]. 

Probability matrices are sparse, and thus can have a compact MTBDD repre- 
sentation. This compactness results from sharing of substructures, and increases 
with the regularity of the original matrix. Though in the worst case exponential, 
compared to sparse matrix representation and depending on the degree of reg- 
ularity of the original matrix, MTBDDs can be much more space-efficient than 
sparse matrices. They also combine efficiently with BDDs. 
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Concurrent probabilistic transition systems with n states that enable at most 
I nondeterministic transitions each can be represented as a nZ x n matrix, which 
can then be stored as an MTBDD. (For simplicity assume that n and I are powers 
of 2). Each row of the matrix represents a single nondeterministic choice, where 
the element in position (i.k, j) represents the probability of reaching state j from 
state i in the fc**' transition that leaves from i. 

Unfortunately, experimental evidence has shown that this simple MTBDD 
representation of concurrent probabilistic systems suffers from a disproportion- 
ately large number of internal nodes, due to the lack of regularity. Instead, we 
will adapt the Kronecker representation originally introduced for space-efficient 
storage of Markov processes as Stochastic Automata Networks [26]. 

5.1 A Modular Description Language for Probabilistic Processes 

We propose a modular description language for concurrent probabilistic sys- 
tems in an attempt to derive a more efficient MTBDD encoding. The system is 
considered as a composition of modules, acting concurrently, more specifically 
via the asynchronous parallel composition of probabilistic processes whose local 
transitions may be dependent on the global state of the system. 

This model bears similarities to the Stochastic Automata Networks (SANs) 
of [26]. One difference between the two approaches is that we consider proba- 
bilistic, as opposed to stochastic processes. Secondly, SANs permit two types of 
process interaction: synchronization between components, and functional transi- 
tions, where the rate or probability with which one component makes a transition 
may depend on the state of another component. For simplicity, we discuss here 
only the latter type of interaction. Most importantly, the motivation is different: 
the fundamental idea with SANs is that since the transition matrix for the com- 
posed system is formulated as a Kronecker expression, only the small matrices 
which make up this expression need to be stored and explicit construction of the 
whole (often huge) transition matrix can be avoided. Although our aim is also 
to obtain a space efficient method of storage, we construct the whole matrix and 
use a Kronecker expression to derive an efficient MTBDD variable ordering. 

We consider the system as a composition of n modules Mi , . . . , M„ , each 
with a set of local variables Vari. Each variable x € Vari has a finite range of 
values, range{x). The local state space Si of module Mi is Yix&Var i"ange{x). 
The global state space of the combined system is then S — rii=i 

Each module defines the transitions that it can make, depending on its cur- 
rent state and the state of the other modules in the system. The behaviour of 
a module Mi is given by a finite non-empty set Li of tuples of the form (c,p), 
where c = is a conjunction of n variable constraints, Cj is a formula 

over Varj and p is a probability distribution over Si. Intuitively, c represents 
the condition under which transitions corresponding to the probability distribu- 
tion p can be made. We can associate with a tuple I = (c,p) the set of global 
states S'; = {s G S' I s ]= c} which satisfy the variable contraints. We require, for 
all modules M,, that the sets Si where I € Li form a disjoint union of S. 
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We interpret the formal description of the behaviour of the modules as fol- 
lows. If the global state of the system is s = (si, . . . , s„) and s € Si for a tuple 
I = (c,p) € Li then the probability of module Mi moving from its current local 
state Si to the local state ti is p{ti). Hence, in each global state of the system, 
any of the n modules can make a move. The behaviour of each individual module 
is essentially that of a Markov chain. It is necessary to decide on some form of 
scheduling between the modules to define the behaviour of the composed system. 
We consider two possibilities: probabilistic and nondeterministic scheduling. In 
the former, each module has an equal probability of being scheduled, giving a 
Markov chain. In the latter, we allow a nondeterministic choice between modules, 
which gives a concurrent probabilistic system as described in Section 2. 



Module Mi: 

(a; = 0) ^ I : (a;' = 0) -f I : (a;' = 1) 
(a; = 1) A (i/ < 1) ^ [x' = 2) 

[x=l) ^{y = 2) ^ [x' = 1) 

{x = 2)^\-.{x' = Q) + \-.{x' = 2) 
Module M 2 : 

(y = 0) ^ I : (y' = 0) + I : (y = 1) 
(y = 1) A (a; < 1) ^ (y' = 2) 

(y = 1) A (a; = 2) ^ {y = 1) 

(y = 2) ^ M = 0) + 1 : = 2) 




Fig. 2. (i) A system composed of two modules, (ii) Transition system of mod- 
ule Ml 



Consider the example shown in Figure 2 of the modules Mi, M 2 , with corre- 
sponding variable sets Vari = {a;} and Var 2 = {y}, where x and y have range 
{0, 1, 2}. Figure 2(i) shows a textual description of the modules. Each line corre- 
sponds to a tuple (c, p) where the condition c and the probability distribution p 
are separated by a — > symbol. For example, in line 1 of module Mi, the condition 
is {x = 0) and the distribution is | : (x' = 0) -I- ^ : {x' = 1), where x' denotes the 
value of X in the state after the transition. Note c = (x = 0) is in fact c = ci A C 2 
where ci = (x = 0) and C 2 = true, i.e. there is no constraint on y. 

5.2 A Kronecker Expression for the Modular Description 

We now derive a Kronecker expression for the transition matrix of the composed 
system. As pointed out in [26], the transition matrix for the composition of n 
non-interacting stochastic automata can be written as: 

n 

Q = ®"=iLi = ^ where Qi = 0 L* 0 (0”=i+ilrij)- 

i=l 

In the above, is the local transition matrix for component i, I„ the identity 
matrix of size n, and Uj the dimension of local matrix Lj. We use the same 
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basic construction here, but with probability matrices for each module, rather 
than Qi. These local matrices are then combined through scheduling rather 
than simply summation. We also account for the fact that the behaviour of one 
module can depend on the state of another. As with functional transitions in 
SANs, this does not affect the overall structure of the Kronecker expression: 
some transitions are simply removed by zeroing out the relevant entry in the 
component matrix. 

For a given module Mi, we want an expression for the corresponding transi- 
tion matrix P^. Since -I- distributes over (8>, we can break the expression up into 
separate matrices Pi,i, such that Pi = restrictions on transi- 

tions are handled by zeroing out some entries of the identity matrices. We first 
convert the information from the module descriptions to vectors. For module Mi 
and line I € Li where I = {c,p) and c = we associate with each Cj the 

column vector Cj, indexed over local states Sj, with Cj(s) = 1 if s ^ Cj and 
Cj(s) = 0 otherwise. Similarly, the probability distribution p is converted to a 
row vector p, indexed over local states from Si, with p(s) = p{s). The unwanted 
elements of the jth identity matrix are removed by a pointwise multiplication 
with the vector Cj. Then: 

Pi.i = ■ InJ 0 (Ci (g) p) (g) • 1 „.) 



Consider the example given previously. We can write the matrices Pip and P 2,2 
for line 1 of module Mi and line 2 of module M 2 respectively, as: 



Pi,i = 






/Ho\ /100\ 

0 0 0 (g) 0 1 0 

\ 000 / \0 01 / 



p 



2,2 = 






0 0 1 




5.3 Module to MTBDD Translation 

The construction of the transition matrix, as described above, can be derived 
directly from the syntax in Figure 2(i) by means of BDD and MTBDD oper- 
ations. First, we encode all the module variables with Boolean variables. For 
convenience, we assume that the range of each variable, x, is a power of 2, 
i.e. range{x) = {0,...,2^ — 1} for some k. Hence, x can be encoded with k 
Boolean variables x\, . . . , Xk, and x' with X\ , . . . , Xk . This gives a set of MTBDD 
row (unprimed) and column (primed) variables for each module variable in the 
system. The ordering of the modules in the textual description and of the module 
variables within them gives us an overall ordering for the Boolean variables in our 
MTBDDs. In our small example, we get x\ < x'^ < xi < x'^ < y\ < y'\ < yi < y'^- 
The column vectors Cj, row vector p and identity matrices can then be 
represented as MTBDDs, using the appropriate Boolean variables. The Kro- 
necker product operation on matrices and vectors represented as MTBDDs can 
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be performed using the Apply(x) operator. The only precaution which must 
be taken is to ensure that the relative order of the MTBDD variables is cor- 
rect. If the MTBDDs / and g represent the matrices F and G respectively 
and all the variables in / precede all those of g in the overall variable ordering 
then Apply(x, /, g) gives the MTBDD for the matrix F 0 G which depends 
on the variables of both. Because we have ensured that our Boolean variables 
are grouped and ordered by module, the Kronecker expression can be com- 
puted easily with Apply(x). Since pointwise multiplication is also carried using 
Apply(x), the MTBDD expression for is as shown below. 

Pi,/ — Apply ( X , Ci , , . . . , , Im — i ? 5 Pi ? • • • 1 J ) ■ 

Since x is commutative and Apply(x,Ci, . . . ,c„) = c, rearranging: 

Pi,/ — ApPLY( X , C, p, 1 , 21 1 ■ ■ ■ 1 — i 1 Ini+i i • ■ • i ) ■ 

We then obtain by summing the Pi_/ for I € Li using Apply(-I-). Finally, we 
compute the MTBDD P for the whole system. For probabilistic scheduling: 

P = ApPLY(x, i, ApPLY(-b,Pi,. . . ,Pn)). 
n 

For nondeterministic scheduling, we add MTBDD variables to encode the sched- 
uler’s choice: one variable, Sj, for each process, where Si = 1 iff module Mi is 
scheduled. This variable can be inserted in the variable ordering next to the vari- 
ables for Mi, to preserve regularity. Returning to our simple example, we would 
have the variable ordering si < xi < x\ < X 2 < x '2 < S 2 < yi < y'l < U 2 < y 2 - 
The computation of P becomes: 

P = AppLY(-b, ITE(si = 1, Pi, 0), ... , ITE(s„ = 1, P„, 0)). 

where ITE(-, •, •) refers to the MTBDD operation IfThenElse(-, •, •). 

The central observation of the paper is that if we convert each of the compo- 
nent matrices into an MTBDD using the Boolean variables and ordering given 
above, then this yields a very efficient state-space encoding through increase in 
regularity (for example, over the matrix obtained through breadth-first search^) 
and sharing. This complies with similar results in [23,30]. Moreover, Kronecker 
product and ordinary sum of two matrices are also very efficient as they respec- 
tively correspond to the MTBDD operations Apply(x) and Apply(-I-). 

6 Experimental Results 

We have implemented an experimental symbolic model checking tool using the 
CUDD package [31]. This package provides support for BDDs and MTBDDs, 
together with matrix multiplication algorithms from [1,14]. 

^ See WWW. cs .bham. ac .uk/'dxp/prism/ for Matlab spy plots of matrices obtained 
via breadth-first search and Kronecker. 
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Our tool performs model checking for PBTL, with and without fairness. The 
MTBDD for a system of modules is automatically generated from its textual 
description using the translation described above. Forward reachability analysis 
is then performed to filter out the unreachable states. 

To model check qualitative properties (typically ‘with probability 1’), reacha- 
bility analysis through fixed point computation suffices. Quantitative properties, 
however, require numerical computation. We work with double-precision floating 
point arithmetic, which is standard for numerical calculations. Our implementa- 
tion relies on the matrix-by-vector multiplication obtained from the matrix-by- 
matrix multiplication algorithms supplied with the CUDD package. The model 
checking of unbounded “until” properties is through the Algorithm EU. For 
purely probabilistic processes we use Jacobi iteration, which has the following 
advantages: it is simple and numerically stable, relies only on the matrix-by- 
vector multiplication, and can deal with very large matrices (since it does not 
change the matrix representing the system). The limiting factor is thus the size 
of the probability vector (which can only be represented efficiently in MTBDDs 
if it has regularity) . 

We have tested our tool on several scalable examples from the literature, in 
particular the kanban problem [12] known from manufacturing and the 
randomized dining philosophers [28]. For more information see 
www.cs.bhajn.ac.uk/~dxp/prism/. Figures 3-6 show a summary of results for 
the dining philosophers model. The concurrent model corresponds to that pre- 
sented in [28], whereas the probabilistic model corresponds to the same model 
with probabilistic scheduling. The tables give the MTBDD statistics, construc- 
tion and model checking times in seconds of the liveness property in [28] (with 
fairness), performed on an Ultra 10 with 380MB. 

The main observations we have made so far are as follows: (1) the variable 
ordering induced from the Kronecker representation results in very compact 
MTBDDs (see comparison of the number of internal nodes in breadth-first and 
Kronecker); (2) because of sharing, MTBDDs allow space-efficiency gains over 
conventional sparse matrices for certain systems; (3) the model construction 
is very fast, including the computation of the reachable subspace; (4) through 
use of probability-1 precomputation step, model checking of qualitative proper- 
ties (with and without fairness) is very fast, and results in orders of magnitude 
speed-up; (5) performance of numerical calculation with MTBDDs is consider- 
ably worse than with sparse matrices, though MTBDDs can potentially handle 
larger matrices and vectors (e.g. up to 5 million) depending on their regularity. 



7 Conclusion 

We have demonstrated the feasibility of symbolic model checking for probabilis- 
tic processes using MTBDDs. In particular, the state encoding induced from the 
Kronecker representation allows us to verify qualitative properties of systems 
containing up to 10^'^ states in a matter of seconds. Moreover, model creation is 
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Model: 


Breadth- first: 


States: 


NNZ: 


Nodes: 


phil 3 
phil 4 
phil 5 


770 
7,070 
64, 858 


2,845 
34, 125 
384, 621 


3,636 
30, 358 
229, 925 



Model: 


Kronecker: 


After reachability: 


States: 


NNZ: 


Nodes: 


States 


NNZ: 


Nodes: 


phil 3 
phil 4 
phil 5 
phil 10 
phil 20 
phil 25 


1,331 
14, 641 
161,051 
2.59 X 10^° 
6.73 X 10^° 
1.08 X 10^® 


4, 654 
67, 531 
919,656 
2.86 X 10“ 
1.43 X 10^^ 
2.86 X 10^® 


647 
1,329 
2,388 
14, 999 
174, 077 
479, 128 


770 
7,070 
64, 858 
4.21 X 10® 
1.77 X 10^® 
1.14 X lO®'^ 


2,845 
34, 125 
384, 621 
4.72 X 10“ 
3.81 X 10“ 
3.06 X 10“ 


873 
2,159 
3,977 
26, 269 
291, 760 
798, 145 



Fig. 3. Statistics for probabilistic models and their MTBDD representation 



Model: 


Breadth- first: 


States: 


NNZ: 


Nodes: 


phil 3 
phil 4 
phil 5 


770 
7,070 
64, 858 


2,910 
35, 620 
408, 470 


4,401 
41,670 
354, 902 



Model: 


Kronecker: 


After reachability 


States: 


NNZ: 


Nodes: 


States 


NNZ: 


Nodes: 


phil 3 
phil 4 
phil 5 
phil 10 
phil 20 
phil 30 


1,331 
14, 641 
161,051 
2.59 X 10“ 
6.73 X 10“ 
1.75 X 10®^ 


34, 848 
1,022,208 
2.81 X 10’’ 
2.90 X 10“ 
1.54 X 10“ 
6.13 X 10'‘^ 


451 
669 
887 
1,977 
4, 157 
6,337 


770 
7,070 
64, 858 
4.21 X 10® 
1.77 X 10“ 
7.44 X 10“ 


20, 880 
511,232 
1.17 X 10’’ 
4.87 X 10“ 
4.19 X 10“ 
2.71 X 10®® 


779 

1556 

2,178 

6,379 

14,429 

22,479 



Fig. 4. Statistics for concurrent models and their MTBDD representation 

very fast (typically seconds) due to the close correspondence between Kronecker 
product and Apply(x), and efficiency of reachability analysis implemented as 
the usual BDD fixed point computation. Likewise, model checking of qualitative 
properties (expressed as ‘with probability 1’ PBTL formulas) is very fast. Many 
quantitative properties, however, are not handled efficiently by our present tool. 
This is due to poor efficiency of numerical computation, such as Jacobi iteration 
or simplex, compared to the corresponding sparse matrix implementation. The 
causes of this are a sudden loss of regularity of the probability vector due to 
explosion in the number of distinct values computed in the process of approxi- 
mation (in the case of Jacobi) or fill-in of the tableau (in the case of simplex). 

Future work will involve further development of the front end for our tool, 
comparison with the prototype tools of [4,9,12], and addressing the inefficiency 
of numerical calculations with MTBDDs. 
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Model: 


Gonstruction: 


Reachability: 


Model checking: 




Time (s): 


Time (s): 


Iterations: 


Time (s): 


Iterations: 


phil3 


0.02 


0.06 


18 


0.02 


6 


phil4 


0.04 


0.33 


24 


0.04 


6 


phil5 


0.07 


1.08 


30 


0.06 


6 


phillO 


0.45 


28.28 


60 


0.23 


6 


phil20 


4.45 


404.15 


120 


0.65 


6 


phil25 


10.81 


766.03 


150 


0.99 


6 



Fig. 5. Times for construction and model checking of probabilistic models 



Model: 


Gonstruction: 


Reachability: 


Model checking: 




Time (s): 


Time (s): 


Iterations: 


Time (s): 


Iterations: 


phil3 


0.02 


0.07 


18 


0.02 


6 


phil4 


0.03 


0.35 


24 


0.04 


6 


phil5 


0.05 


1.00 


30 


0.07 


6 


phillO 


0.24 


27.03 


60 


0.22 


6 


phil20 


1.45 


389.56 


120 


0.49 


6 


phil30 


4.10 


5395.00 


180 


11.40 


6 



Fig. 6. Times for construction and model checking of concurrent models 



Acknowledgements 

The authors Kwiatkowska, Norman and Parker are members of the ARC project 
1031 Stochastic Modelling and Verification funded by the British Council and 
DAAD. We also thank the anonymous referees for their helpful comments. 



References 

1. 1. Bahar, E. Frohm, C. Gaona, G. Hachtel, E.Macii, A. Pardo, and F. Somenzi. 
Algebraic Decision Diagrams and their Applications. Journal of Formal Methods 
in Systems Design, 10(2/3):171-206, 1997. 396, 397, 401, 405 

2. C. Baier. On algorithmic verification methods for probabilistic systems. Habilita- 
tion thesis, 1998. 396, 397, 399, 400, 401 

3. C. Baier, E. Glarke, V. Hartonas-Garmhausen, M. Kwiatkowska, and M. Ryan. 
Symbolic model checking for probabilistic processes. In Proceedings, 24th ICALP, 
volume 1256 of LNCS, pages 430-440. Springer- Verlag, 1997. 396, 397, 401 

4. C. Baier, J.-P. Katoen, and H. Hermanns. Approximate symbolic model checking 
of continuous-time Markov chains. In CONCUR’99, volume 1664 of LNCS, pages 
146-161. Springer- Verlag, 1999. 396, 407 

5. C. Baier and M. Kwiatkowska. Model checking for a probabilistic branching time 
logic with fairness. Distributed Computing, 11:125-155, 1998. 396, 397, 398, 399, 
400 

6. J. Bengtsson, K. G. Larsen, F. Larsson, P. Pettersson, W. Yi, and C. Weise. New 
generation of uppaal. In Proceedings of the International Workshop on Software 
Tools for Technology Transfer, Aalborg, Denmark, July 1998. 396 



Symbolic Model Checking of Probabilistic Processes 409 



7. D. Bertsekas. Dynamic Programming and Optimal Control. Athena Scientific, 
1995. 396 

8. A. Bianco and L. de Alfaro. Model checking of probabilistic and nondetermin- 
istic systems. In Proceedings, FST&TCS, volume 1026 of LNCS, pages 499-513. 
Springer- Verlag, 1995. 396, 398, 399 

9. M. Bozga and O. Maler. On the representation of probabilities over strnctured 
domains. In Proc. CAV’99, 1999. Available as Volume 1633 of LNCS. 396, 407 

10. J. R. Burch, E. M. Clarke, K. L. McMillan, D. L. Dill, and J. Hwang. Symbolic 
model checking: 10^° states and beyond. In LICS’90, June 1990. 395 

11. G. Ciardo and A. Miner. SMART: Simulation and markovian analyzer for relia- 
bility and timing. In Tools Descriptions from PNPM’97, pages 41-43, 1997. 397 

12. G. Ciardo and A. Miner. A data structure for the efficient Kronecker solution of 
GSPNs. In Proc. PNPM’99, 1999. 406, 407 

13. E. Clarke, E. Emerson, and A. Sistla. Automatic verification of finite state con- 
current systems using temporal logic specifications: A practical approach. In Pro- 
ceedings, 10th Annual Symp. on Principles of Programming Languages, 1983. 398, 
399 

14. E. Clarke, M. Fujita, P. McGeer, J.Yang, and X. Zhao. Multi-Terminal Binary 
Decision Diagrams: An Efficient Data Structure for Matrix Representation. In 
International Workshop on Logic Synthesis, 1993. 396, 401, 405 

15. C. Courcoubetis and M. Yannakakis. Markov decision processes and regular events. 
In Proc. ICALP’90, volume 443 of LNCS, pages 336-349. Springer- Verlag, 1990. 
396, 400 

16. C. Courcoubetis and M. Yannakakis. The complexity of probabilistic verification. 
.Journal of the ACM, 42(4):857-907, 1995. 398, 400 

17. L. de Alfaro. How to specify and verify the long-run average behavior of proba- 
bilistic systems. In Proc. LICS’98, pages 454-465, 1998. 396 

18. L. de Alfaro. Stochastic transition systems. In Proc. CONCUR’98, volume 1466 
of LNCS. Springer- Verlag, 1998. 396 

19. L. de Alfaro. Computing minimum and maximum reachability times in probabilis- 
tic systems. In Proc. CONCUR’99, volume 1664 of LNCS, 1999. 397, 400 

20. L. de Alfaro. From fairness to chance. In Proc. PROBMIV’98, volume 21 of 
ENTCS. Elsevier, 1999. 398 

21. G. Hachtel, E. Macii, A. Pardo, and F. Somenzi. Markovian Analysis of Large 
Finite State Machines. IEEE Transactions on CAD, 15(12):1479-1493, 1996. 397 

22. H. Hansson and B. Jonsson. A logic for reasoning about time and probability. 
Formal Aspects of Computing, 6:512-535, 1994. 396, 398 

23. H. Hermanns, J. Meyer-Kayser, and M. Siegle. Multi Terminal Binary Deci- 
sion Diagrams to represent and analyse continuous time Markov chains. In Proc. 
NSMC’99, 1999. 397, 405 

24. M. Kwiatkowska, G. Norman, D. Parker, and R. Segala. Symbolic model checking 
of concurrent probabilistic systems using MTBDDs and simplex. Technical Report 
CSR-99-1, University of Birmingham, 1999. 397 

25. K. McMillan. Symbolic Model Checking. Kluwer Academic Publishers, 1993. 395 

26. B. Plateau. On the Stochastic Structure of Parallelism and Synchronisation Models 
for Distributed Algorithms. In Proc. 1985 ACM SICMETRICS Conference on 
Measurement and Modeling of Computer Systems, pages 147-153, May 1985. 397, 
402, 403 

27. B. Plateau, J. M. Fourneau, and K. H. Lee. PEPS: a package for solving com- 
plex Markov models of parallel systems. In R. Puigjaner and D. Potier, editors. 
Modelling techniques and tools for computer performance evaluation, 1988. 397 



410 



Luca de Alfaro et al. 



28. A. Pnueli and L. Zuck. Verification of multiprocess probabilistic protocols. Dis- 
tributed Computing, 1:53-72, 1986. 396, 406 

29. R. Segala. Modelling and Verification of Randomized Distributed Real-Time Sys- 
tems. PhD thesis, MIT, 1995. 398 

30. M. Siegle. Compact representation of large performability models based on ex- 
tended BDDs. In Fourth International Workshop on Performability Modeling of 
Computer and Communication Systems (PMCCSf), pages 77-80, 1998. 405 

31. F. Somenzi. CUDD: CU decision diagram package. Public software, Colorado 
University, Boulder, 1997. 396, 397, 405 

32. M. Vardi. Automatic verification of probabilistic concurrent finite-state programs. 
In Proceedings, FOCS’85, pages 327-338. IEEE Press, 1987. 396, 398 



Symbolic Reachability Analysis 
Based on SAT- Solvers 



Parosh Aziz Abdulla^, Per Bjesse^, and Niklas Een^ 



^ Uppsala University and Prover Technology, Sweden 
paroshSdocs .uu.se 

^ Chalmers University of Technology, Sweden 
{bjesse , een}@cs . chalmers . se 



Abstract. The introduction of symbolic model checking using Binary 
Decision Diagrams (BDDs) has led to a substantial extension of the 
class of systems that can be algorithmically verified. Although BDDs 
have played a crucial role in this success, they have some well-known 
drawbacks, such as requiring an externally supplied variable ordering 
and causing space blowups in certain applications. In a parallel develop- 
ment, SAT-solving procedures, such as Stalmarck’s method or the Davis- 
Putnam procedure, have been used successfully in verifying very large 
industrial systems. These efforts have recently attracted the attention of 
the model checking community resulting in the notion of bounded model 
checking. In this paper, we show how to adapt standard algorithms for 
symbolic reachability analysis to work with SAT-solvers. The key ele- 
ment of our contribution is the combination of an algorithm that removes 
quantifiers over propositional variables and a simple representation that 
allows reuse of subformulas. The result will in principle allow many ex- 
isting BDD-based algorithms to work with SAT-solvers. We show that 
even with our relatively simple techniques it is possible to verify systems 
that are known to be hard for BDD-based model checkers. 



1 Introduction 

In recent years model checking [CES86,QS82] has been widely used for algorith- 
mic verification of finite-state systems such as hardware circuits and communi- 
cation protocols. In model checking, the specification of the system is formulated 
as a temporal logical formula, while the implementation is described as a finite- 
state transition system. Early model-checking algorithms suffered from state 
explosion, as the size of the state space grows exponentially with the number 
of components in the system. One way to reduce state explosion is to use sym- 
bolic model checking [BCMD92,McM93], where the transition relation is coded 
symbolically as a boolean expression, rather than explicitly as the edges of a 
graph. Symbolic model checking achieved its major breakthrough after the in- 
troduction of Binary Decision Diagrams (BDDs) [Bry86] as a data structure for 
representing boolean expressions in the model checking procedure. An impor- 
tant property of BDDs is that they are canonical. This allows for substantial 



S. Graf and M. Schwartzbach (Eds.): TACAS/ETAPS 2000, LNCS 1785, pp. 411-425, 2000. 
© Springer-Verlag Berlin Heidelberg 2000 



412 



Parosh Aziz Abdulla et al. 



sub-expression sharing, often resulting in a compact representation. In addition, 
canonicity implies that satisfiability and validity of boolean expressions can be 
checked in constant time. However, the restrictions imposed by canonicity can 
in some cases lead to a space blowup, making memory a bottleneck in the appli- 
cation of BDD-based algorithms. There are examples of functions, for example 
multiplication, which do not allow sub-exponential HDD representations. Fur- 
thermore, the size of a HDD is dependent on the variable ordering which in many 
cases is hard to optimize, both automatically and by hand. BDD-based methods 
can typically handle systems with hundreds of boolean variables. 

A related approach is to use satisfiability solvers, such as implementations 
of Stalmarck’s method [Sta] and the Davis-Putnam procedure [Zha97]. These 
methods have already been used successfully for verifying industrial systems 
[SS00,Bor97,Bor98,SS90,GvVK95]. SAT-solvers enjoy several properties which 
make them attractive as a complement to BDDs in symbolic model checking. 
For instance, their performance is less sensitive to the size of the formulas, and 
they can in some cases handle propositional formulas with thousands of vari- 
ables. Furthermore, SAT-solvers do not suffer from space explosion, and do not 
require an external variable ordering to be supplied. Finally, satisfiability solving 
is an NP-complete problem, whereas BDD-construction solves a #P-complete 
problem [Pap94] as it is possible to determine the number of models of a BDD in 
polynomial time. #P-complete problems are widely believed to be harder than 
NP-complete problems. 

The aim of this work is to exploit the strength of SAT-solving procedures in 
order to increase the class of systems amenable to verification via the traditional 
symbolic methods. We consider modifications of two standard algorithms — 
forward and backward reachability analysis — where formulas are used to char- 
acterize sets of reachable states [Bje99]. In these algorithms we replace BDDs 
by satisfiability checkers such as the ProVER implementation of Stalmarck’s 
method [Sta] or SATO [Zha97j. We also use a data structure which we call Re- 
duced Boolean Circuits (RBCs) to represent formulas. RBCs avoid unnecessarily 
large representations through the reuse of subformulas, and allow for efficient 
storage and manipulation of formulas. The only operation of the reachability 
algorithms that does not carry over straightforwardly to this representation is 
quantification over propositional variables. Therefore, we provide a simple pro- 
cedure for the removal of quantifiers, which gives adequate performance for the 
examples we have tried so far. 

We have implemented a tool FixIt [Ecn99] based on our approach, and car- 
ried out a number of experiments. The performance of the tool indicates that 
even though we use simple techniques, our method can perform well in compar- 
ison to existing ones. 

Related Work. Bounded Model Checking (BMC) [BCC“*'99,BCCZ99,BCRZ99] 
is the first approach in the literature to perform model checking using SAT- 
solvers. To check reachability, the BMC procedure searches for counterexamples 
(paths to undesirable states) by “unrolling” the transition relation k steps. The 
unrolling is described by a (quantifier-free) formula which characterizes the set 
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of feasible paths through the transition relation with lengths smaller than or 
equal to k. The search can be terminated when the value of k is equal to the 
diameter of the system — the maximum length of all shortest path between states 
in the system. Although the diameter can be specified by a logical formula, 
its satisfiability is usually hard to check, making BMC incomplete in practice. 
Furthermore, for “deep” transition systems, formulas characterizing the set of 
reachable states may be much smaller than those characterizing witness paths. 
Since our method is based on encodings of sets of states, it may in some cases 
cope with systems which BMC fails to analyze as it generates formulas that are 
too large. 

Our representation of formulas is closely related to Binary Expression Di- 
agrams (BEDs) [AH97,HWA97]. In fact there are straightforward linear space 
translations back and forth between the representations. Consequently, RBCs 
share the good properties of BEDs, such as being exponentially more succinct 
than BDDs [AH97]. The main difference between our approach and the use of 
BEDs is the way in which satisfiability checking and existential quantification 
is handled. In [AH97], satisfiability of BEDs is checked through a translation 
to equivalent BDDs. Although many simplifications are performed at the BED 
level, converting to BDDs during a fixpoint iteration could cause degeneration 
into a standard BDD-based fixpoint iteration. In contrast, we check satisfiability 
by mapping RBCs back to formulas which are then fed to external SAT-solvers. 
In fact, the use of SAT-solvers can also be applied to BEDs, but this does not 
seem to have been explored so far. Furthermore, in the BED approach, existential 
quantification is either handled by introducing explicit quantification vertices, or 
by a special transformation that rewrites the representation into a form where 
naive expansion can be applied. We use a similar algorithm that also applies an 
extra inlining rule. The inlining rule is particularly effective in the case of back- 
ward reachability analysis, as it is always applicable to the generated formulas. 
To our knowledge, no results have been reported in the literature on applica- 
tions of BEDs in symbolic model checking. We would like to emphasize that we 
view RBCs as a relatively simple representation of formulas, and not as a major 
contribution of this work. 



2 Preliminaries 

We verify systems described as synchronous circuits constructed from elementary 
combinational gates and unit delays — a simple, yet popular, model of computa- 
tion. The unit delays are controlled by a global clock, and we place no restriction 
on the inputs to a circuit. The environment is free to behave in any fashion. 

We define the state-holding elements of a circuit to be the primary inputs and 
the contents of the delays, and define a valuation to be an assignment of boolean 
values to the state-holding elements. The behaviour of a circuit is modelled as a 
state-transition graph where (1) each valuation is a state; (2) the initial states 
comprise all states that agree with the initial values of the delays; and (3) there 
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Fig. 1. A simple circuit built from combinational gates and delays 



is a transition between two states if the circuit can move between the source 
state and the destination state in one clock cycle. 

We construct a symbolic encoding of the transition graph in the standard 
manner. We assign every state-holding element a propositional state variable Vi, 
and make two copies of the set of state variables, s = {vq,vi, . . . ,Vk} and 
s' = {v'qjV'i,... ,u^}. Given a circuit we can now generate two characteristic 
formulas. The first of the characteristic formulas, Init{s) = f\iVi 4'i^ defines 
the initial values of the state-holding elements. The second characteristic for- 
mula, Tr{s,s') = ^ defines the next-state values of state-holding 

elements in terms of the current-state values. 

Example 1. The following formulas characterize the circuit in Figure 1: 

Init = (uq ^ T) a (u 3 <-*■ T) 

Tr = (ug ^ (vo A ui)) A (ug ^ (u 2 V V 3 )) 

We investigate the underlying state-transition graph by applying operations at 
the formula level. In doing so we make use of the following three facts. First, 
the relation between any points in a given circuit can be expressed as a propo- 
sitional formula over the state-holding variables. Second, we can represent any 
set S of transition-graph states by a formula that is satisfied exactly by the 
states in S. Third, we can lift all standard set-level operations to operations on 
formulas (for example, set inclusion corresponds to formula-level implication and 
set nonemptiness checking to satisfiability solving, respectively). 

3 Reachability Analysis 

Given the characteristic formulas of a circuit and a formula Bad(s), we define 
the reachability problem as that of checking whether it is possible to reach a 
state that satisfies Bad{s) from an initial state. As an example, in the case of 
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Fig. 2. The intuition behind the reachability algorithms 



the circuit in Figure 1, we might be interested in whether the circuit could reach 
a state where the two delay elements output the same value (or equivalently, 
where the formula vg <-> vg is satisfiable). We adapt two standard algorithms for 
performing reachability analysis. In forward reachability we compute a sequence 
of formulas Fi{s) that characterize the set of states that the initial states can 
reach in i steps: 



Fg{s) = Init 

Fi+i{s') = toProp{3s. Tr{s,s') A Fi{s))) 

Each computation of Fi+i gives rise to a Quantified Boolean Formula (QBF), 
which we translate back to a pure propositional formula using an operation 
toProp (defined in in Section 5) . We terminate the sequence generation if either 
(1) Fn{s) A Bad{s) is satisfiable: this means that a bad state is reachable; hence 
we answer the reachability problem positively; or (2) Vfe=o ^k{s) Vfc=o ^k{s) 
holds: this implies that we have reached a fixpoint without encountering a bad 
state; consequently the answer to the reachability question is negative. 

In backward reachability we instead compute a sequence of formulas Bi(s) 
that characterize the set of states that can reach a bad state in i steps: 

Bq{s) = Bad 

Bi+i{s) = toProp{3s' . Tr{s, s') A Bi{s'))) 

In a similar manner to forward reachability, we terminate the sequence genera- 
tion if either (1) B„(s) A Init{s) is satisfiable, or (2) Vfc=o ^k{s) Vfe=o ^k{s) 
holds. 

Figure 2 shows the intuition behind the algorithms. We remark that the two 
reachability methods can be combined by alternating between the computation 
of Fi_|_i and The generation can be terminated when either a fixpoint is 

reached in some direction, or when Fn and intersect. However, we do not 
make use of hybrid analyses in this paper. 

We need to address three nontrivial issues in an implementation of the adapted 
reachability algorithms. First, we must avoid the generation of unnecessarily 
large formula characterizations of the sets Fi and Bi — formulas are not a canon- 
ical representation. Second, we must define the operation toProp in such a way 
that it translates quantified boolean formulas to propositional logic without 
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Fig. 3. A non-reduced Boolean Circuit and its reduced form 



needlessly generating exponential results. Third, we must interface efficiently to 
external satisfiability solvers. The remainder of the paper explains our solutions, 
and evaluates the resulting reachability checker. 

4 Representation of Formnlas 

Let Bool denote the set of booleans; Vars denote the set of propositional vari- 
ables, including a special variable T for the constant true, and Op denote the 
set 

We introduce the representation Boolean Circuit (BC) for propositional for- 
mulas. A BC is a directed acyclic graph, (V, E). The vertices V are partitioned 
into internal nodes, Vi, and leaves, Vl. The vertices and edges are given at- 
tributes as follows: 

— Each internal vertex v G Vi has three attributes: A binary operator op(v) G 
Op, and two edges left{v), right{v) G E. 

— Each leaf G Vl has one attribute: var{v) G Vars. 

— Each edge e S E has two attributes: signie) G Bool and target{e) G V. 

We observe that negation is coded into the edges of the graph, by the sign 
attribute. Furthermore, we identify edges with subformulas. In particular, the 
whole formula is identified with a special top-edge having no source vertex. The 
interpretation of an edge as a formula is given by the standard semantics of A, <--> 
and ^ by viewing the graph as a parse tree (with some common sub-expressions 
shared). Although A and ^ are functionally complete, we choose to include <-> 
in the representation as it would otherwise require three binary connectives to 
express. Figure 3 shows an example of a BC. 

A Reduced Boolean Circuit (RBC) is a BC satisfying the following properties: 
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redttce(AND, left G RBC, right e RBC) 
if (left = right) return left 
elif (left = aright) return _L 
elif (left = T) return right 
elif (right = T) return left 
elif (left = _L) return _L 
elif (right = _L) return _L 
else return nil 



reduce (E quiv, left G RBC, right £ RBC) 
if (left = right) return T 
elif (left = -iright) return _L 
elif (left = T) return right 
elif (left = _L) return -iright 
elif (right = T) return left 
elif (right = _L) return -ileft 
else return nil 



mfc_Comp(op £ Op, left £ RBC, right £ RBC, sign £ Bool) 
result := reduce {op, left, right) 
if (result 7 ^ nil) 

return id(result, sign) - id returns result or -iresult depending on sign 
if (right < left) 

(left, right) ;= (right, left) - Swap the values of left and right 
if (op = Equiv) 

sign := sign xor si 5 n(left) xor sign(right) 
left := unsigned (left) 
right := unsigned (right) 

result := lookup {KBC-env, (op, left, right)) - Look for vertex in environment 
if (result = nil) 

result := mseri(RBC_env, (op, left, right)) 
return id (result, sign) 



Fig. 4. Pseudo-code for creating a composite RBC from two existing RBCs 

1. All common subformulas are shared so that no two vertices have identical 
attributes. 

2. The constant T never occurs in an RBC, except for the single-vertex RBCs 
representing true or false. 

3. The children of an internal vertex are syntactically distinct, left{v) 7 ^ 
right{v). 

4. If op {v) = <-!■ then the edges to the children of v are unsigned. 

5. For all vertices v, left{v) < right{v), for some total order < on BCs. 

The purpose of these constraints is to identify as many equivalent formulas as 
possible, and thereby increase the amount of subformula sharing. For this reason 
we allow only one representation of ^{4> ip) 4=^ (->(/) ip) (in 4 above), and 
{cp A Ip) 4=^ {ip A (p) (in 5 above). 

The RBCs are created in an implicit environment, where all existing subfor- 
mulas are tabulated. We use the environment to assure property (1). Figure 4 
shows the only non-trivial constructor for RBCs, mk.Comp, which creates a com- 
posite RBC from two existing RBCs (we use x £ Vars((/)) to denote that a; is a 
variable occurring in the formula (p) . It should be noted that the above properties 
only takes constant time to maintain in mk^Comp. 
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5 Quantification 

In the reachability algorithms we make use of the operation toProp to translate 
QBF formulas into equivalent propositional formulas. We reduce the translation 
of a set of existential quantifiers to the iterated removal of a single quantifier 
after we have chosen a quantification order. In the current implementation an 
arbitrary order is used, but we are evaluating more refined approaches. 

Figure 5 presents the quantification algorithm of our implementation. By 
definition we have: 



3a; . (f>{x) 4=^ ^(-L) V <p{T) (*) 

The definition can be used to naively resolve the quantifiers, but this may yield 
an exponential blowup in representation size. To try to avoid this, we use the 
following well-known identities (applied from left to right) whenever possible: 

Inlining: 

3a; . {x tp) A (j){x) 4 =^ (where x ^ Vars(i/;)) 

Scope Reduction: 

3x . 4>{x) A tp 4 =^ {3x.(j){x)) A Ip (where a; ^ Vars('0)) 

3a; . (p{x) V ip{x) 4=^ {3x.(p{x)) V {3x.'ip{x)) 

When applicable, inlining is an effective method of resolving quantifiers as it im- 
mediately removes all occurrences of the quantified variable x. The applicability 
of the transformation relies on the fact that the formulas occurring in reacha- 
bility often have a structure that matches the rule. This is particularly true for 
backward reachability as the transition relation is a conjunction of next state 
variables defined in terms of current state variables f\^ v[ 'fpiis). 

The first step of the inlining algorithm temporarily changes the represen- 
tation of the top-level conjunction. From the binary encoding of the RBC, we 
extract an equivalent set representation /\{(pQ,(pi, . . . ,(pn}- If the set contains 
one or more elements of the form x p}, the smallest such element is removed 
from the set and its right-hand side ip is substituted for x in the remaining 
elements. The set is then re-encoded as an RBC. 

If inlining is not applicable to the formula (and variable) at hand, the trans- 
lator tries to apply the scope reduction rules as far as possible. This may result 
in a quantifier being pushed through an Or (represented as negated And), in 
which case inlining may again be possible. 

For subformulas where the scope can no longer be reduced, and where inlining 
is not applicable, we resort to naive quantification (*). Reducing the scope as 
much as possible before doing this will help prevent blowups. Sometimes the 
quantifiers can be pushed all the way to the leaves of the RBC, where they can 
be eliminated. 

Throughout the quantification procedure, we may encounter the same sub- 
problem more than once due to shared subformulas. For this reason we keep a 
table of the results obtained from all previously processed subformulas. 
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- Global variable processed tabulates the results of the performed quantifications. 

quantjnaive{(j) G RBC, x € Vars) 

result = subst{4>, x, _L) V subst{4>, x, T) 
insert(processed, f>, x, result) 
return result 

quant-reduceScope{(f) G RBC, x G Vars) 
if (x ^ Vars(i^)) return (j> 
if (0 = x) return T 

result := /ootep (processed, rf), x) 
if (result 7^ nil) 
return result 

- In the following <j) rnust be composite and contain x: 
if [(j>op = Equiv) 

result := quanGnaive{4>, x) 
elif (not 4>sign) - Operator And, unsigned 

if (x ^Vaxs{4neft)) result := A quant. reduce Seope{(f> right, x) 
elif {x ^ Vars( 0 rigfei)) result := quant.redueeScope{(f>ieft , x) A (fright 
else result := quant.naive{(j), x) 

else - Operator And, signed (“On”) 

result := quant.inline{-^(j}ieft, x) V quant.inline{-i(j)right, x) 

inseri(processed, (j>, x, result) 
return result 

quant. inline {(f> G RBC, x G Vars) - “Main” 

C := colleetConjuncts{(p) -Merge all binary Ands at the top of (j> into a 

“big” conceptual conjunction (returned as a set). 
:= findDef (C , x) -Return the smallest formula tp such that {x tp) 

is a member of C. 

if {tf ^ nil) 

C' := C \ (x ^ %p) - Remove definition from C . 

return subst{makeConj{C'), x, if) - makeConj builds an RBC. 

else 

return quant.reduceSeope{(p, x) 



Fig. 5. Pseudo-code for performing existential quantification over one variable. 
By ((left we denote left{target{(p)) etc. We use A, V as abbreviations for calls to 
mk.Comp 

6 Satisfiability 

Given an RBC, we want to decide whether there exists a satisfying assignment 
for the corresponding formula by applying an external SAT-solver. The naive 
translation — unfold the graph to a tree and encode the tree as a formula — 
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has the drawback of removing sharing. We therefore use a mapping where each 
internal node in the representation is allocated a fresh variable. This variable 
is used in place of the subformula that corresponds to the internal node. The 
generated formula is the conjunction of all the definitions of internal nodes and 
the literal that defines the top edge. 

Example 2. The right-hand RBC in Figure 3 is mapped to the following formula 
in which the ik variables define internal RBC nodes: 

(lo ^ ^ii A 12 ) 

A {i\ ^ is u) 

A (l2 ^ *3 A 14 ) 

A {is ^ X A z) 

A {i 4 z A y) 

A ->io 

A formula resulting from the outlined translation is not equivalent to the original 
formula without sharing, but it will be satisfiable if and only if the original 
formula is satisfiable. Models for the original formula are obtained by discarding 
the values of internal variables. 



7 Experimental Results 

We have implemented a tool FixIt [Ecn99] for performing symbolic reachability 
analysis based on the ideas presented in this paper. The tool has a fixpoint 
mode in which it can perform both forward and backward reachability analysis, 
and an unroll mode where it searches for counterexamples in a similar manner 
to the BMC procedure. We have carried out preliminary experiments on three 
benchmarks: a multiplier and a barrel shifter (both from the BMC distribution), 
and a swapper (defined by the authors) . The first two benchmarks are known to 
be hard for BDD-based methods. 

In all the experiments, ProVER outperforms Sato, so we only present mea- 
surements made using PROVER. Furthermore, we only present time consumption. 
Memory consumption is much smaller than for BDD-based systems. Garbage 
collection has not yet been implemented in FixIt, but the amount of simulta- 
neously referenced memory peaks at about 5-6 MB in our experiments. We also 
know that the memory requirements of PROVER are relatively low (worst case 
quadratic in the formula size). The test results for FixIt are compared with 
results obtained from VIS release 1.3, BMC version l.Of and CADENCE SMV 
release 09-01-99. 



The Multiplier. The example models a standard 16x 16 bit shift-and-add mul- 
tiplier, with an output result of 32 bits. Each output bit is individually verified 
against the C6288 combinational multiplier of the ISCAS’85 benchmarks by 



Symbolic Reachability Analysis Based on SAT-Solvers 421 



Table 1. Experimental results for the multiplier 



Bit 


sec 


sec 


Unroll 

sec 


BMC 

sec 


VIS 

sec 


SMV 

sec 


0 


0.8 


2.0 


0.7 


1.0 


5.3 


41.4 


1 


0.9 


2.3 


0.7 


1.4 


5.4 


41.3 


2 


1.1 


3.0 


0.8 


2.0 


5.3 


42.5 


3 


1.8 


3.9 


0.9 


4.0 


5.5 


42.6 


4 


3.0 


6.1 


1.2 


8.2 


6.2 


[>450 MB] 


5 


7.2 


9.9 


1.8 


19.9 


10.2 


- 


6 


24.3 


21.5 


3.8 


66.7 


32.9 


- 


7 


100.0 


61.9 


11.8 


304.6 


153.5 


- 


8 


492.8 


224.7 


45.2 


1733.7 


[>450 MB] 


- 


9 


2350.6 


862.6 


197.8 


9970.8 


- 


- 


10 


11927.5 


3271.0 


862.8 


54096.8 


- 


- 


11 


60824.6 


13494.3 


3838.0 


- 


- 


- 


12 


- 


50000.0 


16425.8 


- 


- 


- 



checking that we cannot reach a state where the computation of the shift-and- 
add multiplier is completed, but where the selected result bit is not consistent 
with the corresponding output bit of the combinational circuit. 

Table 1 presents the results for the multiplier. The SAT-based methods out- 
perform both VIS and SMV. The unroll mode is a constant factor more efficient 
than the fixpoint mode. However, we were unable to prove the diameter of the 
system by the diameter formula generated by BMC, which means that the verifi- 
cation performed by the unroll method (and BMC) should be considered partial. 



The Barrel Shifter. The barrel shifter rotates the contents of a register file R 
with one position in each step. The system also contains a fixed register file i?o, 
related to R in the following way: if two registers from R and i?o have the same 
contents, then their neighbours also have the same contents. We constrain the 
initial states to have this property, and the objective is to prove that it holds 
throughout the reachable part of the state space. The width of the registers is 
log |i?| bits, and we let the BMC tool prove that the diameter of the circuit is 
\R\. 

Table 2 presents the results for the barrel shifter. No results are presented 
for VIS due to difficulties in describing the extra constraint on the initial state 
in the VIS input format. 

The backward reachability mode of FixIt outperforms SMV and BMC on 
this example. The reason for this is that the set of bad states is closed under 
the pre-image function, and hence FixIt terminates after only one iteration. 
SMV is unable to build the BDDs characterising the circuits for larger problem 
instances. The BMC tool has to unfold the system all the way up to the diameter, 
producing very large formulas; in fact, the version of BMC that we used could 
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Table 2. Experimental results for the barrel shifter 



\ R \ 


sec 


sec 


sec 


BMC 

sec 


Diam 

sec 


SMV 

sec 


2 


1.7 


0.1 


0.1 


0.0 


0.0 


0.0 


3 


2.3 


0.1 


0.1 


0.0 


0.0 


0.1 


4 


3.0 


0.1 


0.2 


0.0 


0.0 


0.1 


5 


42.4 


0.2 


0.3 


0.1 


0.1 


44.2 


6 


848.9 


0.2 


0.5 


0.3 


0.1 


[>450 MB] 


7 


5506.6 


0.4 


0.5 


0.4 


0.2 


- 


8 


[>3 h] 


0.5 


1.0 


1.2 


0.3 


- 


9 


- 


0.8 


1.6 


2.4 


0.6 


- 


10 


- 


1.1 


2.3 


8.6 


0.8 


- 


11 


- 


1.5 


2.3 


3.3 


1.1 


- 


12 


- 


2.3 


4.1 


25.6 


1.5 


- 


13 


- 


2.6 


3.9 


7.1 


2.0 


- 


14 


- 


3.2 


7.8 


80.1 


2.6 


- 


15 


- 


3.7 


8.6 


75.1 


3.5 


- 


16 


- 


4.3 


12.1 


150.0 


4.4 


- 


17 


- 


6.7 


11.0 


34.6 


7.9 


- 


18 


- 


8.7 


30.5 


7 


7 


- 


19 


- 


9.2 


15.6 


? 


7 


- 


20 


- 


13.5 


49.1 


7 


7 


- 


30 


- 


51.4 


452.1 


7 


7 


- 


40 


- 


230.5 


2294.7 


7 


7 


- 


50 


- 


501.5 


8763.3 


7 


7 


- 



not generate formulas for larger instances than size 17 (a size 17 formula is 
2.2 MB large). The oscillating timing data for the SAT-based tools reflects the 
heuristic nature of the underlying SAT-solver. 

The Swapper. N nodes, each capable of storing a single bit, are connected 
linearly: 

® 

At each clock-cycle (at most) one pair of adjacent nodes may swap their values. 
From this setting we ask whether the single final state in which exactly the 
first L^/2J nodes are set to 1 is reachable from the single initial state in which 
exactly the last [N/2\ nodes are set to 1. Table 3 shows the result of verifying 
this property. 

Both VIS and SMV handle the example easily. Fixlx can handle sizes up to 
14, but does not scale up as well as VIS and SMV, as the representations get 
too large. This illustrates the importance of maintaining a compact represen- 
tation during deep reachability problems; something that is currently not done 
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Table 3. Experimental results for the swapper 



N 


sec 


™"Bwd 

sec 


'■“'^Unroll 

sec 


BMC 

sec 


VIS 

sec 


SMV 

sec 


3 


0.2 


0.2 


0.2 


0.0 


0.3 


0.0 


4 


0.3 


0.3 


0.2 


0.0 


0.3 


0.0 


5 


0.6 


0.5 


0.3 


0.1 


0.3 


0.0 


6 


0.9 


1.5 


1.8 


7.2 


0.4 


0.1 


7 


1.7 


3.7 


131.2 


989.5 


0.4 


0.1 


8 


3.8 


10.4 


[>2 h] 


[>2 h] 


0.4 


0.1 


9 


9.7 


58.9 


- 


- 


0.4 


0.1 


10 


27.7 


187.1 


- 


- 


0.4 


0.1 


11 


74.1 


779.2 


- 


- 


0.5 


0.2 


12 


238.8 


4643.2 


- 


- 


0.6 


0.2 


13 


726.8 


[>2 h] 


- 


- 


0.7 


0.3 


14 


2685.7 


- 


- 


- 


0.7 


0.4 


15 


[>2 h] 


- 


- 




0.7 


0.6 


20 


- 


- 


- 


- 


1.6 


7.9 


25 


- 


- 


- 


- 


3.3 


53.0 


30 


- 


- 


- 


- 


15.1 


263.0 


35 


- 


- 


- 


- 


39.1 


929.6 


40 


- 


- 


- 


- 


89.9 


2944.3 



by FixIt. However, BMC does even worse, even though the problem is a strict 
search for an existing counterexample — something BMC is generally good at. 
This shows that fixpoint methods can be superior both for proving unreachabil- 
ity and detecting counterexamples for certain classes of systems. 



8 Conclusions and Future Work 

We have described an alternative approach to standard BDD-based symbolic 
model checking which we think can serve as a useful complement to existing 
techniques. We view our main contribution as showing that with relatively simple 
means it is possible to modify traditional algorithms for symbolic reachability 
analysis so that they work with SAT-procedures instead of HDDs. The resulting 
method gives surprisingly good results on some known hard problems. 

SAT-solvers have several properties which make us believe that SAT-based 
model checking will become an interesting complement to BDD-based tech- 
niques. For example, in a proof system like Stalmarck’s method, formula size 
does not play a decisive role in the hardness of satisfiability checking. This is 
particularly interesting since industrial applications often give rise to formulas 
which are extremely large in size, but not necessarily hard to prove. 
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There are several directions for future work. We are currently surveying sim- 
plification methods that can be used to maintain compact representations. One 
promising approach [AH97] is to improve the local reduction rules to span over 
multiple levels of the RBC graphs. We are also interested in exploiting the struc- 
ture of big conjunctions and disjunctions, and in simplifying formulas using 
algorithms based on Stalmarck’s notion of formula saturation [Bje99]. As for 
the representation itself, we are considering adding if-then-else and substitution 
nodes [HWA97]. Other ongoing work includes experiments with heuristics for 
choosing good quantification orderings. 

In the longer term, we will continue to work on conversions of BDD-based al- 
gorithms. For example, we have already implemented a prototype model checker 
for general (fair) CTL formulas. Also, employing traditional BDD-based model 
checking techniques such as front simplification and approximate analysis are 
very likely to improve the efficiency of SAT-based model checking significantly. 

Many important questions related to SAT-based model checking remain to 
be answered. For example, how should the user choose between bounded and 
fixpoint-based model checking? How can SAT-based approaches be combined 
with standard approaches to model checking? 
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Abstract. The control state reachability problem is decidable for well- 
structured infinite-state systems like unbounded Petri Nets, Vector Ad- 
dition Systems, Lossy Petri Nets, and Broadcast Protocols. An abstract 
algorithm that solves the problem is given in [ACJT96,FS99]. The al- 
gorithm computes the closure of the predeeessor operator w.r.t. a given 
upward-closed set of target states. When applied to this class of verifica- 
tion problems, traditional (infinite-state) symbolic model checkers suffer 
from the state explosion problem even for very small examples. We pro- 
vide BDD-like data structures to represent in a compact way collections 
of upwards closed sets over numerical domains. This way, we turn the ab- 
stract algorithm of [ACJT96,FS99] into a practical method. Preliminary 
experimental results indicate the potential usefulness of our method. 



1 Introduction 

In the last years many efforts have been made to extend the theoretical re- 
sults and practical methods developed for finite-state systems [BCB+90] to sys- 
tems with infinite state space (see e.g. [ACJT96,BM99,BW98,EFM99,FS99]). 
This class of systems comprises well-known examples like Vector Addition Sys- 
tems [Min67], extensions of Petri Nets [Cia94,Ter94], Integral Relational Au- 
tomata [Cer94], and more recent examples like Broadcast Protocols [EN98] and 
Lossy Petri Nets [BM99]. The control state reachability problem is decidable 
for all previous systems [ACJT96,BM99,EFM99,Fin90,FS99]. The abstract algo- 
rithm of [ACJT96,FS99] computes the closure of the predecessor operator w.r.t. 
a given upward-closed set of states. The algorithm can be used to check, e.g., 
invariant properties like mutual exclusion [DEP99] and coverability for markings 
of Petri Nets [AJKP98]. 

As in the finite-state case, the success of symbolic model checking for this 
class of problems depends on the data structures used as implicit representation 
of sets of states. Over numerical domains, upward-closed sets can be represented 
via a sub-class of integer arithmetic constraints (see e.g. [ACJT96,DEP99]). In 
this setting, the state-space generated by the algorithm of [ACJT96,FS99] can 
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be represented as a large disjunction of arithmetic constraints. In [DEP99], the 
authors tested constraint-based model checking methods over integers (based 
on a solver for Presburger arithmetic [BGP97]) and reals (based on polyhe- 
dra [HHW97]) on verification problems that can be expressed via upward-closed 
sets. Though the examples in [DEP99] would be considered of negligible size in 
finite-state model checking (e.g. 6 transitions and 10 variables, cf. [BCB+90]), 
the methods taken into consideration suffer from the state explosion problem^. 
Some of the experiments required (when terminating) execution times in the or- 
der of days. Based on these observations, it seems natural to look for BDD-like 
data structures to represent ‘compactly’ the generalization of boolean formulas 
we are interested in. 

In this paper we propose a new symbolic representation for upward-closed 
sets based on the sharing trees of Zampunieris and Le Charlier [ZL94]. Sharing 
trees are acyclic graphs used to represent large sets of tuples, e.g., of integer 
numbers. The intuition behind the choice of this data structure is the following. 
An upward-closed set U is determined by its finite set of generators (tuples of 
integers). Thus, we can represent the set U via a sharing tree whose paths cor- 
respond to its generators. This way, we managed to turn the abstract algorithm 
of [ACJT96,FS99] into a ‘practical method’ working on the examples studied 
in [DEP99,Ter94] in acceptable time cost. 

Technically, our contributions are as follows. We introduce a logic (the logic 
U) where collections of upward-closed sets can be represented as disjunctive for- 
mulas. 7Y-formulas are used for verification problems of infinite-state systems as 
boolean formulas are used for the finite-state case. We show that sharing trees 
can be used to obtain compact representations of Z/f-formulas (there exist a U- 
formula that can be represented using a sharing tree whose size is logarithmic in 
the size of the formula). We show how basic operations on 7^-formulas (e.g. con- 
junction and disjunction) can be implemented symbolically on the corresponding 
sharing trees. Sharing trees can be viewed as the BDDs for 7Y-formulas. 

In practical cases (e.g., during the symbolic computation of the closure of the 
predecessor operator), sharing trees may still become very large. For this reason, 
we propose polynomial time algorithms that can be used to eliminate redundant 
paths. As we prove in the paper, the problem of removing all redundancies 
from a sharing tree representing a 7Y-formula is co-NP hard (in the size of the 
sharing tree). The same techniques can be used to give sufficient conditions 
for the subsumption test of sharing trees representing T^-formulas (i.e. for the 
termination test of the algorithm of [ACJT96]). The complete test is co-NP hard 
in the size of the sharing trees. 

As an application of our method, we have implemented the algorithm 
of [ACJT96] in the case of Vector Addition Systems. The implementation makes 
use of the sharing tree library of [Zam97]. First experimental results indicate the 
potential usefulness of our method. 



^ One would say ‘symbolic state explosion problem’, in fact, the above cited methods 
operate on implicit representations of infinite sets of states. 
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Plan of the Paper. In Section 2, we define the logic lA. In Section 3, we intro- 
duce the symbolic representation of ^//-formulas via sharing trees. In Section 4, 
we define simulation relations for nodes of sharing trees and discuss their ap- 
plication in the operations for ^//-formulas. In Section 5, we define a symbolic 
model checking procedure for Vector Addition Systems. In Section 6, we present 
related work. In Section 7, we address some conclusions and future perspectives 
for our work. 

The extended version of the paper (containing all proofs) is available as 
technical report MPI-1999-2-07 of Max-Planck-Institut fiir Informatik [DR99]. 

2 The Logic of Upward-Closed Sets 

In this section we introduce the logic U that we use to define collections of 
upward-closed sets. Let V = {a;i,...,a;fe} be a finite set of variables. The set of 
^//-formulas is defined by the following grammar. 



where c G ZU{— c»}. 7Y-formulas are interpreted over Z^. We use t to denote the 
valuation (ti, , tk), where G Z is the valuation for variable Xi. We consider 
the following order over tuples: t ^ t' \S ti < t^ for i : 1, ... ,k (— oo < c for 
any c € Z). When restricted to positive values, ^ is a well-quasi ordering (see 
e.g. [ACJT96,FS99]). Given a tuple t, we define as the upward-closed set 
generated by t, namely, = { t' \ t ^ t' }. Satisfaction of a formula wrt. a 
valuation t is defined as follows: 

— t \= Xi > c iS ti > c; 

— t 1= 4)i A 4)2 iff t 1= 4)i and t |= 4>2; 

— t 1= 4>i V 4>2 iff t 1= 4>i or f |= 4>2; 

— t \= -I- cjxi\ iff ^ 4> and t' is obtained from t replacing ti with ti c. 

The denotation of a formula 4>, namely |4>], is defined as the set of all evaluations 
t such that t 1= 4>. A formula 4>i is subsumed by a formula 4>2, written 4>i |= 4*2, 
if [‘f’ll ^ Two formulas are equivalent if their denotations coincide. 

Note that, whenever we restrict the domain of interpretation of our formulas 
to positive integers (say Z+), the class of 7Y-formulas denotes all upward-closed 
sets, i.e., all sets / C Z^ such that if t e / then C I. 

All formulas can be reduced to disjunctive formulas, i.e., to formulas having 
the following form^: 



Notation. In the rest of the paper we use 4>, 4), etc. to denote arbitrary lA- 
formulas, and etc. to denote disjunctive formulas. 

The set of generators of a disjunctive formula <p are defined as 

Adding formulas of the form Xi > —oo when necessary. 



4> ::= Xi > c I 4> A 4> I 4> V 4> I 4>[xi -|- c/xi], 




2 
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gen{(p) = { {ci, . . . ,Ck) \ {x\ > ci A . . . A Xfc > Cfc) is a disjunct in Lp }. 

Thus, disjunctive formulas are in one-to-one correspondence with their set of 
generators modulo logical equivalences. The minimal elements (wrt. of genipp) 
are denoted by min{(p). Note that |(/3] = UtGmm We say that a disjunctive 
formula is in normal form whenever gen(jp) = min(jp). As an example, consider 
the formula tp = (x > lAg> 2) V(x>3Ag> 1) V (x > 2 A g > 0). Then, 
gen(ip) = {(1, 2), (3, 1), (2, 0)}, and min((p) = {(1, 2), (2, 0)}, i.e., (p is not in 
normal form. 



2.1 Operations on Formulas in Disjunctive Form 

Disjunction and Conjunction. Formulas in disjunctive form are closed under V. 
Furthermore, given the disjunctive formulas ip and tjj, the disjunctive formula 
for ip A if is defined as follows: \J t(^gen{v),t'&genwi^i > rnax{ti,t[) A ... A 
Xk > max(fk,t'k))j i-®-) gen{pAip) = {s | 3t g gen{p),t' g gen{'ip) and Si = 
t')}. Note that the resulting formula may not be in normal form. 



Substitution. The formula p[xi + c/xi\ is equivalent to the formula p' obtained 
from p by replacing every atom Xi > d with Xi > d — c (— oo — c = — oo for any 
c g Z), i.e., gen{p[xi + c/xi\) = {t' | t ' -I- c = t' = tj j ^ i, t g gen{p)}. 

Satisfaction wrt. a tuple. Given a valuation t, we first note that t\=pifl there 
exists t' g gen{p) such that t' =4 t- Thus, checking t \= p can be done in time 
linear in the size of p. 

Subsumption. Let p and tp be in disjunctive form. We can check p \= tp in time 
quadratic in the size of the formulas. In fact, p \= tp holds iff for all t g genipp) 
there exists t' g gen{tp) such that t' t. 

It is important to remark that the subsumption test is much harder for 
arbitrary f^-formulas, as stated in the following theorem. 

Theorem 1. Given two arbitrary W-formulas and 'k, checking that d) |= T is 
co-NP complete in the size of the formulas. 



Reduction in normal form. Given a disjunctive formula p we can reduce it 
in normal form by eliminating all ‘redundant’ generators from gen{p), i.e., all 
t g gen{p) such that there exists t' g gen{p), t t' , t' ^ t. The reduction can 
be done in time quadratic in the size of p. 

All previous operations depend on the set of ‘generators’ of disjunctive formu- 
las. In the following section we introduce a special data structure, called sharing 
tree [ZL94], for handling large sets of generators. We show how to use this data 
structure to represent and manipulate symbolically formulas of the logic lA. 
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3 Sharing Trees 

In this paper we specialize the original definition of [ZL94] as follows. We call 
a A:-sharing tree a rooted directed acyclic graph {N, V, root, end, val, succ) where 
N = {root} U Ni . . . U Nk U {end} is the finite set of nodes, {Ni is the set of 
nodes of layer i and, by convention, Nq = {root} and N^+i = {end}), val : 
iV ^ ZU {T, _L} is a labeling function for the nodes, and succ : N 2^ defines 
the successors of a node. Furthermore, 

1. valin) = T if and only if n = root', 

2. val(n) = _L if and only if n = end', 

3. succ{end)=%', 

4. for i : 0, . . . , fc, forall n € Ni, succ{n) C Ni+i and succ{n) yf 0; 

5. forall n G N, forall ni,n 2 G succ{n), if n\ yf ri 2 then val{n\) yf val{n 2 )- 

6. for i : 0, ...,fc, forall ni,ri 2 G Ni s.t. ni yf ri 2 , if val{ni) = val{n 2 ) then 
succ(ni) yf succ{n 2 ). 

In other words, a fc-sharing tree is an acyclic graph with root and terminal node 
such that: all nodes of layer i have successors in the layer i+l (cond. 4); a node 
cannot have two successors with the same label (cond. 5); finally, two nodes with 
the same label in the same layer do not have the same set of successors (cond. 6). 
We say that S' is a pre-sharing tree if it respects conditions (l)-(4) but possibly 
not (5) and (6). 

Notation. In the rest of the paper we use root^ , N^ , succ^ etc. to refer to the 
root, set of nodes, successor relation etc. of the sharing-tree S. 

A path of a fc-sharing tree is a sequence of nodes (ni, . . . , Um) such that ni+i G 
succ(ni) i : 1, .. . ,m-l. Paths will represent tuples of size fc of integer numbers. 
Formally, we use elem{S) to denote the set of elements represented by the fc- 
sharing tree S'. 

elem{S) = { (wa/(ni), . . . , r>a^nfe)) | (T, ni, . . . , rifc, _L) is a path of S }. 

Condition 5 and 6 ensure the maximal sharing of prefixes and suffixes among 
the paths (elements) of the sharing tree. We define the ‘size’ of a sharing tree as 
the number of its nodes and edges. Note that the number of tuples in elem{S) 
can be exponentially larger than the size of S. Given a node n of the z-th layer 
of a fc-sharing tree S, the sub-(sharing)tree Sn rooted at n is the fc — z -I- 1- 
sharing tree obtained as follows. We first isolate the graph rooted at n and 
consisting of all nodes reachable from n (this subgraph has fc — z -|- 1 layers and 
a terminal node). Then, we add a layer with the single node root and we set 
succ{root) = {n}. From the previous definition, e/em(S'„) consists of all tuples 
{val{n),mi+i, . . . ,nrik) obtained from tuples {m\, . . . ,val{n),mi+i, . . . ,nrik) of 
elem{S). 

As shown in [ZL94], given a set of tuples F of size fc, there exists a unique 
(modulo isomorphisms of graphs) sharing tree such that elem{S) = F. In the 
same paper the authors give algorithms for the basic set-operations on the set of 
elements represented by the sharing trees. The table in Fig. 1 gives the specifi- 
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Operation 


Complexity 


elem{union{S , T)) = elem{S) U elem{T) 
elem{intersection[S , T)) = elem{S) 0 elem{T) 
member{t, S) iff t £ elem{S) 
contained{S , T) iff elem{S) C elem{T) 
is-empty{S) iff elem{S) = 0 


0{max(edges{S),edges(T)) + Red) 
0{min{edges{S),edges{T)) + Red) 
0{size(t)) 

0{edges{S)) 

O(const) 



Fig. 1. Operations on the sharing trees S and T: edges{S)=No.edges of S 



cation and the complexity in terms of the size of sharing trees, for the operation 
we will consider in the rest of the paper: union, intersection, emptiness, contain- 
ment, and equality test. In [ZL94], the authors show that the operations in Fig. 1 
can be safely applied to pre-sharing trees that satisfy condition 5 only. The cost 
for intersection and union depends also on the cost Red in Fig. 1, of re-arranging 
condition 6. This task can be achieved using the algorithm presented in [ZL94] 
with cost quadratic in the number of nodes of the resulting sharing trees. 

3.1 Symbolic Representation of W-Formulas 

We first show how to represent Z^-formulas in disjunctive form, and then show 
how to define disjunction, conjunction, subsumption and reduction in normal 
form over the resulting data structure. 

Let ip he a, iY-formula in disjunctive form over si, . . . ,Xfe. We define S^p as 
the fc-sharing tree such that elem(Sp) = gen{p). The denotation of a A:-sharing 
tree S is then defined as [S'] = Utgeiem(S) Clearly, |<p] = We say that 
is irredundant if tp is in normal form, i.e., there exists no < G elem{Sip) such that 
t' ^ t for t' S elem{Sip) distinct from t. The following proposition explains the 
advantages of using sharing trees for representing Z^-formulas. 

Proposition 1. There exist a disjunctive formula in normal form p such that 
the corresponding sharing tree has size (no. of nodes and arcs) logarithmic 
in the size of p. 

As an example, consider the Z/f-formula > 1 A Wi > 0) V (?;, > 

Q f\Wi > 1). The corresponding disjunctive formulas p (obtained by distributing 
A) is \J c+d>i NiLi > Ci Awi > di) for c,d G Z™. This formula has 0(2"*) 
disjuncts. Also note that p is in normal form. In contrast, the sharing tree 
shown in Fig. 2 has size logarithmic in p and polynomial in (each layer has 
two nodes and at most four arcs). 

3.2 Symbolic Operations for W-Formulas 

In this section we show how operations on the disjunctive formulas p and if) 
can be defined symbolically on their representations and S.^. We use the 
term symbolically because the algorithms that we propose work directly on the 
graphs Sp and and not by enumerating the elements that they represent. 
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Fig. 2. Sharing tree for an exponential formula in DNF 



Disjunction. Let S^p and S.^ be the A:-sharing trees representing the formulas 
(in disjunctive form) ip and ip. To build a sharing tree with eZem(S'ipvV') = 
gen{ip) U gen{ip), we define union{Sp, 3^1,), where union is the operation 

in Fig. 1. In [ZL94], it has been show that the size of the sharing-tree S',^vV' 
most quadratic in the size of and and can be computed in time quadratic 
in the size of the input sharing-trees. 



Conjunction. Given S^p and we build follows. We first define a pre- 
sharing tree P with the following components: (i) = {root} U W U . . . U U 

{end} with Ni = {(n, m) | n G (i.e. a node in P correspond 

to a pair consisting of a node of Sp and a node of (at the same layer); 
(ii) val^{{n,m)) = max{val^'^{n),val^'i^{m)), and (iii) for all {n,m) G Ni U 
. . . U Nn, we set succ^{{n,m)) = {{n',m') \ n' G succ^'^{n),m' G succ'^'>‘ (m)}, 
succ^ {root) = iVi, and for all {n,m) G Nk we set succ^ {{n,m)) = {end}. We 
obtain the sharing-tree Sp/\.^ from P by enforcing conditions (5-6) of Section 3 
with the algorithms proposed in [ZL94]. 



Substitution. Given the sharing tree Sp we build a new sharing tree S'y,[£Cj+c/a;i] 
such that elem{Sp[xi+c/xi]) = gen{(p[xi + cjxpP) as follows. Sp[xi+c/xi] has the 
same components as Sp except from the valuation function: for every node n G 



n: 






(n) = val^r (n) — c, and for every node n G N} 



V?[a?i+c/a;J 



with j 7 ^ i, val^r[xii+c/xi](jPi _ yal^‘p{n). This way, we obtain a well-formed 
sharing tree. The complexity of the construction is linear in the number of nodes 
of Sp, i.e., potentially logarithmic in the number of its elements. 



Satisfaction wrt. a tuple. Ghecking that t \= ip on the sharing tree Sp has cost 
linear in the size of p, i.e., following from Remark 1, possibly logarithmic in the 
size oi p. In fact, the following theorem holds. 

Theorem 2. Let S' be a fc-sharing tree and t be a vector of length k. We can 
check if t is subsumed by S in time linear in the number of edges of S. 



Subsumption. The subsumption problem is harder: the best possible algorithm 
for subsumption is exponential in the size of the trees, as shown by the following 
theorem. 
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Theorem 3. The subsumption problem for two (irredundant) fc-sharing trees 
is co-NP complete in the size of the sharing trees. 

Following from the previous result, the cost of checking subsumption may be 
exponential in the number of edges of the input sharing trees. The result follows 
from the fact that f^-formulas in disjunctive form can be represented compactly 
via sharing-tress. 

Reduction in normal form. Let S^p be the sharing tree associated to a disjunctive 
formula tp. We consider now the following problem: what is the complexity of 
computing the sharing-tree for the normal form of ip (i.e. the sharing-tree S 
such that elem{S) = min{ip ))7 The following theorem shows that it is as hard 
as checking subsumption. 

Theorem 4. Given a fc-sharing tree S, computing the irredundant fc-sharing 
tree S' such that [S'] = |S"] is co-NP hard. 

Let S'! and S2 be two ^-sharing trees. Note that, if elem{Si) C elem{S2) then 
[5'i] C IS'2]. Besides giving a sufficient condition for checking subsumption, the 
previous fact suggests a possible strategy to reduce the cost of the ‘complete’ 
test. We first compute T = minus{S\, S2) (polynomial in the size of S\, S2) and 
then test T ^ S'2 on the (possibly) smaller sharing tree T. 

In the next section we give more interesting polynomial-time sufficient con- 
ditions for the subsumption test, based on a notion of simulation between nodes 
of fc-sharing trees. We will see that this notion of simulation is also useful to 
reduce sharing-trees and ’’approximate” the reduction in normal form. 

4 Simulations for Nodes of a fc-Sharing Tree 

In the previous section we have proved that the subsumption problem for two 
f^-formulas represented as sharing-trees and the computations of generators of 
the normal form of a Z^-formula represented as a sharing-tree, are co-NP hard. 
In this section we will introduce ‘approximations’ of the subsumption relation 
that can be tested more efficiently. More precisely, given two nodes n and m 
of a sharing tree S we are looking for a relation such that: ‘implies’ 

ISnl C I^„l. 

Definition 1 (Forward Simulation). Given two sharing tree S and T, let n 
be a node of the t-th layer of S, and m be a node of the z-th layer of T. We 
say that n is simulated by m, written if val^fn) > vaf" {m) and for all 

s G succ^fn) there exists t G succ^fm) such that 

Note that, if S' = T then the simulation relation is reflexive and transitive. 

Let fatherfn) be the set of fathers of a node n at layer z {fathersfn) C Ni-x). 
We define the backward simulation as follows: 

Definition 2 (Backward simulation). Given two sharing tree S and T, let n 
be a node of the z-th layer of S, and m be a node of the z-th layer of T. We say 
that n is backwards simulated by m, written n^^m, if val^fn) > vaf" {m) and 
for all s G fathers^ (n) there exists t G father s'^ {m) such that s^^t. 
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The following result (taken from [HHK95]) shows that the previous simulations 
can be computed efficiently. 

Theorem 5 (Prom [HHK95]). The forward and backward simulation rela- 
tions between the nodes of the sharing tree S and the nodes of the sharing 
tree T can be computed in 0{m ■ n) where m is the sum of the number of nodes 
in S and in T, and n is the sum of the number of edges in S and in T. 

In the rest of this section we will focus on properties and algorithms for 
the forward simulation. The results and algorithms can be reformulated for the 
backward simulations by replacing the successor relation with the father relation. 



4.1 Properties of the Simulation 

The following propositions relate subsumption and the simulation . 

Lemma 1. Given the sharing trees S and T, let Sn and be the sub-sharing 
trees rooted at nodes n and m, respectively. If then [S’k] C l^ml- 

The converse does not hold (in accord with the co-NP hardness result for sub- 
sumption). As a counterexample, take the two trees in Fig. 3. The curly arrows 
represent the simulation relation between nodes of S and T. Note that none of the 
nodes of layer 2 in T simulates the single node of S at the same layer. However, 
the denotation of S are contained in that of T. In fact, (1, 1, 2,0) ^ (1,2, 2,1) 
and (1,0,0, 2) ^ (1,2, 1,2). The following theorem follows from Lemma 1. 




Fig. 3. The forward simulation is incomplete wrt. subsumption 



Theorem 6. Let roots, ends and rooix, endr be the root and terminal nodes 
of S and T, respectively. If roots'^^rooix then [S'] C |T]. Symmetrically, if 
ends^^ endx then [S'] C |T]. 



The previous theorem gives us sufficient conditions for testing subsumption. 
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4.2 Use of Simulations to Remove Redundancies 

As for the subsumption test, the simulations we introduced in Section 4 can be 
used to ‘approximate’ the exact normalization procedure. For this purpose, we 
introduce a rule that allows us to exploit the information given from (one of) 
the simulation relation(s) in order to ‘locally’ remove edges of a sharing tree. 

Definition 3 (Edge Removal). Given a sharing tree S with node N and suc- 
cessors succ, let us assume that for n S N there exist s,t € succ{n) 
(s yf t) such that s^^t. Then, we define remove{S,n) as the pre-sharing tree 
with successor relation succ’ obtained from S by setting succ'(n) = succ(n)\{s}. 

The following proposition states the ‘correctness’ of the previous rule. 

Proposition 2. (1) S and remove{S,n) have the same denotations, i.e., [S'] = 
|remowe(5', n)]; (2) the simulation relation for S and remove{S, n) coincides. 

A possible strategy to apply Def. 3 consists of the ‘on-the-fiy’ removal of edges 
during the computation of the simulation relation. Specifically, during a bottom- 
up traversal of the sharing tree, we first apply Rule 3 to every node of a layer, 
then compute the simulation relation for the nodes of the same layer, move to the 
next layer, and so on. The rule to remove edges is applied exhaustively at each 
step. In fact, given s G succ(n), let us assume that there exists u,t G succ{n) 
such that u^^^s, and By transitivity, u'^^t holds, as well, i.e., we can 

still remove u after having removed s. The pre-sharing tree remove{S,n) may 
violate the condition 6 of the definition of sharing trees (Section 3). However, 
as already mentioned in the course of the paper, condition 6 can be restored 
using an algorithm proposed in [ZL94]. Similar algorithms can be defined for 
the backward simulation. It is important to note that, though an application of 
Rule 3 does not change the forward simulation (Fact (2) of Prop. 2), it may 
change the backward simulation (and, vice versa, the removal of edges according 
to the backward relation may change the forward simulation). As a consequence, 
we get better and better results iterating the application of the algorithm for 
removing edges for the backward-forward simulations. A simplified version of 
Rule 3 that requires only a local test for every node of a sharing tree is given as 
follows. 

Definition 4 (Local Edge Removal). Given a sharing S tree with node N 
and successors succ, let assume that for n G N there exist s,t G succ{n) 
(s yf t) such that val{s) > val{t) and succ(s) C succ{t). Then, we define 
local jremove{S, n) as the pre-sharing tree with successor relation sued obtained 
from S by setting succ'(n) = succ(n) \ {s}. 

Though less effective than Rule 3, Rule 4 can be paired with it in order to 
simplify the computation of the simulation. In the following section we show 
how to incorporate the previous ideas in a model checking procedure for an 
example of integer system. 
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5 Invariant Checking for Vector Addition Systems 

A Vector Addition System (VAS) consists of n variables x\,...,Xn ranging over 
positive integers, and m transition rules given as guarded command over the 
data variables. For every j, transition i contains a guard Xj > Cij and an as- 
signment Xj := Xj + dij; if dij < 0 then Cij > dij. States are tuples of positive 
numbers and executions are sequences of tuples toti . . .ti. . . where is ob- 
tained from ti by applying (non-deterministically) one of the transition rules. 
The predecessor operator pre takes as input a set of states (tuples) F and re- 
turns the set of predecessors of F . Properties like mutual exclusion and coverabil- 
ity can be represented through upward-closed sets [AC.JT96,DEP99]. Checking 
safety properties expressed as upward-closed set for Petri Nets is decidable using 
the following algorithm taken from [ACJT96]. Let F be an upward-closed set 
(denoting unsafe states). To test the safety property ‘always ~^{F)’ we compute 
symbolically the closure of the relation pre, say pre*{F), and then we check that 
the initial configuration is not part of the resulting set. From [ACJT96], pre*{F) 
is still an upward-closed set. The termination test is based on the containment 
relation, namely we stop the computation whenever pre’^'^^(F) C pre'^ (F) . 

U-Logic based Model Checking. Let ipu a Z^-formula representing a collection of 
upward-closed set U. The predecessor relation for VAS can be represented as the 
following Z^-formula: 

pre{ipu)= V {‘Pi A ipu[xi + di^i/xi\. . ,[xk + di^k/xk\) 

where Pi = X\ > Cip A . . . A Xn > Ci^n- In other words, by using the results in 
the previous sections, starting from we can compute the sharing tree Sp^e^ 
that represents \/1.^q pre^ (U) . The termination test is implemented by the sub- 
sumption test for sharing trees. The algorithms based on the simulations that 
we described in this paper can be used for a weaker termination test and for re- 
moving redundancies from the intermediate results. We have define a prototype 
implementation for the algorithm using the library of [Zam97]. We discuss next 
some preliminary experimental results. 

5.1 A Case-Study: The Table Manufacturing System 

The table manufacturing system of Teruel [Ter94] is a production system mod- 
eled via a weighted Petri Net with 7 places and 6 transitions. The values of the 
weights on the transitions vary from 2 to 4. This Petri Net can be modeled using 
a VAS with 13 variables, 7 for the places and 6 extra variables, say Ti, . . . ,Tg, 
to keep track of the number of firings of each transition. As shown in [Tcr94], 
all deadlock-free initial markings are exactly the predecessors of the set of states 
where the first transition is fired at least 3 times, and all the others are fired 
at least twice (i.e. U = Ti > 3 A Aj>i A — ^)- In [DEP99], different general 
purpose constraint-based checkers have been used to compute the set of prede- 
cessors via backward reachability. While other tools fail from terminate within 
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Fig. 4. Flags: NV=No. Variable; NR=No. Rules; ET=Execution Time; LR=Use 
of local reduction; FSR=Frequency in the use of sim. reduction (__=not 
used); NS=No Steps; NE=No. of Elem. of the result sharing tree; Ra- 
tio=Nodes/(NV*NE) 



1 day of execution, the tool based on the Omega library of Bultan, Gerber and 
Pugh’s [BGP97] terminates after 19 hours and 50 minutes on a Sun Ultra Sparc, 
and the ‘specialized’ checker proposed in [DEP99] (see Sect. 6) terminates after 
1090 seconds. Sharing trees allows us to dramatically speed up the computation. 
Our prototype implementation (based on the library of [Zam97]) terminates af- 
ter 39 seconds on a Sun Ultra Sparc (see Fig. 4). In a first experiment we have 
not removed the redundancies from Spre* , whereas in a second experiment we 
have applied the reduction based on the forward simulation (every 5 steps) (see 
Fig 4). Simulation-based reduction (every 5 steps) allows us to reduce the set of 
states of a factor of ten (note: removing all redundancies yields 450 elements). 
Other examples are considered in the extended version of this paper [DR99] . 



6 Related Work 

In [ACJT96], the authors introduce a symbolic representation {constraint sys- 
tem) for collections of upward-closed sets. Their representation corresponds to 
disjunctive ^//-formulas. Traditional symbolic methods for handling linear con- 
straints (e.g. polyhedra or Presburger arithmetics) suffer however from the state- 
explosion problem when applied to this type of ‘constraints’. In [DEP99], a more 
efficient representation based on sequences of pairs bitvector- constant is proposed 
for representing the state-space of broadcast protocols, and, as special case, of 
VAS. In this paper we have shown how to obtain more compact and efficient 
representations via sharing trees. 

In [Zam97,GGZ95], the authors apply sharing trees to represent the state- 
space of concurrent systems: a state is a tuple of values and a set of states 
is represented as a sharing tree. Note the difference with our approach. We 
represent a set of states via a tuple, and collections of sets of states via a sharing 
tree. The complexity issues are different when lifting the denotation to collections 
of sets of states (see Section 3). In [Zam97], Zampunieris makes an accurate 
comparison between sharing trees and binary decision diagrams (BDDs) [Bry86] . 
When the aim is to represent tuples of (unbounded) integers (as in our case), the 
layered structure of sharing trees allows optimizations that seem more difficult 
using BDDs (or extensions like multi-valued DDs [SKM'**90] or multi-terminal 
DDs [GFZ96]). 
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Our approach shares some similarities with recent works on interval deci- 
sion diagrams (IDDs) [ST99] and clock decision diagrams (CDDs) for timed 
automata [BLP’^99]: all approaches make use of acyclic graphs to represent dis- 
junctions of interval constraints. However, the use of simulations as abstractions 
for handling efficiently large disjunctions has not been considered in the other ap- 
proaches. More experimentations are needed for a better comparison of all those 
methods. Finally, the PEP tool [Gra97] provides a BDD-based model checking 
method for Petri Nets (with a fixed-a-priori number of tokens) [Wini97]. We 
are not aware of BDDs-based representations for the ‘constraints’ we are inter- 
ested in, e.g., for verification problems of Petri Nets with a possibly unbounded 
number of tokens. 



7 Conclusions and Future Work 

We have proposed a new symbolic representation for ‘constraints’, we called U- 
formulas, that can be used in verification problems for infinite-state integer sys- 
tems (e.g., coverability of Petri Nets). The representation is based on the sharing 
trees of Zampunieris and Le Charlier. For our purposes, we lift the denotation 
of a sharing tree to the upward-closed set ‘generated’ by the tuples contained in 
the sharing tree. We have studied the theoretical complexity of the operations 
for sharing trees wrt. this denotation. Furthermore, we have given sufficient con- 
ditions for testing subsumption (co-NP hard for ^//-formulas) we discover thanks 
to the view of 7^-formulas as acyclic graphs. In fact, the conditions are based on 
simulations relations for nodes of sharing trees. 

Though the termination test for the algorithm of [ACJT96] applied to collec- 
tions of upward-closed sets (~ ^//-formulas ~ sharing trees) may be very costly^, 
testing for membership of the initial configuration (when it can be expressed 
with a conjunctive formula) can be done efficiently (Theorem 2). This gives us 
an effienct method to detect violations of safety properties. 

The implementation is currently being optimized, but the preliminary experi- 
mental results are already promising. The type of optimizations we are interested 
in are: heuristics for finding ‘good’ orderings of variables; symbolic representa- 
tion of the transition system (e.g. PADs [ST99]); partial order reductions (see 
e.g. [AJKP98] for an application to the coverability problem of Petri Nets). Fi- 
nally, it would be interesting to extend our techniques to more general classes of 
constraints. 



Acknowledgments. The authors would like to thank Jean-Marc Talbot, Andreas 
Podelski, and Witold Charatonik for fruitful discussions, and Denis Zampunieris 
for having made the sharing tree library available for our experiments. 

® Quadratic for disjunctive formulas, but disjunctive formulas suffers from the state 
explosion; exponential for sharing trees or arbitrary W-formulas. 
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An Experimental Evaluation for Asynchronous 
Concurrent Systems* 
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Abstract. BDD-based symbolic model checking has been successful in 
verification of a wide range of systems. Recently, constraint-based ap- 
proaches, which use arithmetic constraints as a symbolic representation, 
have been used in symbolic model checking of infinite-state systems. 
We argue that use of constraint-based model checking is not limited 
to infinite-state systems. It can also be used as an alternative to BDD- 
based model checking for systems with integer variables which have finite 
but large domains. In this paper we investigate the trade-offs between 
these two approaches experimentally. We compare the performance of 
BDD-based model checker SMV to the performance of our constraint- 
based model checker on verification of several asynchronous concurrent 
systems. The results indicate that constraint-based model checking is a 
viable option for verihcation of asynchronous concurrent systems with 
large integer domains. 



1 Introduction 

Model checking has been used in verification of diverse applications ranging from 
hardware protocols [McM93] to software specifications [CAB+98]. The success of 
model checking has been partially due to use of efficient data structures like Bi- 
nary Decision Diagrams (BDDs) which can encode boolean functions in a highly 
compact format [Bry86] . The main idea in BDD-based symbolic model checking 
is to represent sets of system states and transitions as boolean logic formulas, 
and manipulate them efficiently using the BDD data structure [BCM+90]. 

An important property of the BDD data structure is that it supports opera- 
tions such as intersection, union, complement, equivalence checking and existen- 
tial quantifier elimination (used to implement relational image computations) — 
which also happen to be the main operations required for model checking. How- 
ever, an efficient encoding for boolean domains may not be efficient for all vari- 
able types. For example, BDD-based model checkers can be very inefficient in 
representing arithmetic constraints [CAB+98]. 

* This work was supported in part by NSF grant CCR-9970976 and a University of 
California Regents’ Junior Faculty Fellowship. 
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Another shortcoming of the BDD representation is its inability to encode infi- 
nite domains. Without abstraction, BDDs cannot be used for analyzing infinite- 
state systems — even those with just one unbounded integer. BDDs encode all 
underlying datatypes as boolean variables; hence all BDD-based model checkers 
inherently require the underlying types to be bounded. 

Recently, arithmetic constraints have been used as a symbolic representation 
in model checking [AHH96,BGP97]. For example, HyTech, a symbolic model 
checker for hybrid systems, encodes real domains using linear constraints on 
real variables [AHH96] . We developed a model checker for integer based systems 
which uses Presburger arithmetic (integer arithmetic without multiplication) 
constraints as its underlying state representation [BGP97,BGP99]. Our model 
checker uses the Omega library [KMP+95] to manipulate Presburger arithmetic 
constraints. In [DP99] model checking queries are converted into constraint logic 
programs, and a GLP(R) library is used to verify concurrent systems by mapping 
integer variables to real domains. 

Gonstraint representations allow verification of infinite-state systems since 
they can represent variables with infinite domains. There are algorithms for 
intersection, union, complement, equivalence checking and existential quantifier 
elimination for both real and integer constraint representations mentioned above. 
However model checking becomes undecidable for infinite-state systems. Hence 
the fixpoint computations are not guaranteed to converge. This problem is ad- 
dressed using conservative approximation techniques [BGP99] which guarantee 
convergence but do not guarantee a definite answer, i.e., the model checker 1) 
may report that the property is verified, 2) provide a counter-example demon- 
strating violation of the property, or 3) report that the analysis is inconclusive. 

Using arithmetic constraints one can also represent variables with finite do- 
mains. We just have to add additional constraints which show the range of values 
that an integer variable can take. An interesting issue is, then, comparing the 
performance of BDD-based model checking to constraint-based model checking 
for finite-state systems with integer variables. 

In this paper we compare the performance of a BDD-based model checker 
(SMV [McM93]) and a constraint-based model checker (our model checker based 
on Omega library [BGP97,BGP99]) in verification of asynchronous concurrent 
systems with integer variables. On the extreme case where integer variables can 
take only two values, they can be treated as boolean variables and represented 
using BDDs. Using a constraint-representation would be very inefficient in such 
a case. On the other hand, although BDD-based model checkers are not capable 
of handling systems with unbounded integers, if the variables are restricted to a 
finite set of values, they can be represented using a set of boolean variables using 
a binary encoding. Our goal in this paper is to investigate the middle ground 
between these two extremes where the integer variables are neither unbounded 
nor have only two possible valuations. 

We perceive efforts in constraint-based model checking as not only a way to 
solve infinite-state verification problems, but also as a way to deal with prob- 
lems with large variable domains using formalisms that are more expressive than 
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boolean logic formulas. However, because of the added expressive power, manip- 
ulation algorithms for these formalisms have higher complexity than correspond- 
ing algorithms for HDDs. These powerful algorithms may not be worthwhile to 
use for small domains because of their high complexity. On the other hand, for 
large domains their complexity maybe justified. The question is, when is the use 
of integer constraint representations justified instead of BDD encodings? In this 
paper we investigate this issue experimentally on verification of asynchronous 
concurrent systems. 

The rest of the paper is organized as follows. We first discuss other related 
approaches to symbolic model checking in Sect. 2. In Sect. 3, we give a brief 
overview of symbolic model checking. After presenting the example concurrent 
systems in Sect. 4, we discuss the experimental results we obtained using BDD 
and constraint-based model checkers in Sect. 5. Finally, we present our conclu- 
sions and future directions. 



2 Related Work 

Another approach to infinite-state model checking is to use automata-based rep- 
resentations. Automata can be used to represent arithmetic constraints on un- 
bounded integer variables [WB95,BKR96,KSA98]. An arithmetic constraint on k 
integer variables is represented by a /c-track automata that accepts a string if 
it corresponds to a fc-dimensional integer vector (in binary representation) that 
satisfies the corresponding arithmetic constraint. Again, since the automata rep- 
resentation supports the necessary operations, it can be used in symbolic model 
checking. 

The constraint and automata-based representations provide two different 
ways of implementing model checking computations for systems with unbounded 
integer variables. In [SKR98] these two approaches are compared experimentally 
for reachability analysis of several concurrent systems. The results show no clear 
winner. On some problem instances the constraint representation is superior, 
on some others automata representation is. In automata-based representations, 
restricting variables to fixed finite domains ends up converting the automata 
representation to a model isomorphic to BDDs [KSA98]. Hence, for the experi- 
ments we conduct in this paper the automata-based representation is equivalent 
to BDD-based model checking. 

Using a BDD-based model checker such as SMV [McM93] for checking sys- 
tems with integer variables can easily result in inefficient encodings of arithmetic 
constraints [CAB+98]. It is pointed out both in [YMW97] and [CAB“^98] that 
SMV can be very inefficient in constructing BDDs for integer variables. This 
inefficiency can be resolved for linear arithmetic constraints by using a better 
variable ordering as explained in [CAB+98]. For non-linear constraints, how- 
ever, there is no efficient BDD representation [Bry86]. In [CABN97] SMV is 
augmented with a constraint solver for non-linear constraints. This technique is 
not applicable to the systems we analyze in this paper because of the restrictions 
put on the types of systems that can be analyzed. 
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Another approach to dealing with integer variables in BDD-based model 
checking is to use abstractions. In [CGL92], a conservative abstraction method 
is presented for model-checking infinite-state programs. The main idea is to pro- 
duce a finite model of the program using a suitable abstraction technique (e.g., 
congruence modulo an integer, single-bit abstraction, symbolic abstraction), and 
then to check the property of interest on the abstraction. For systems such as the 
ones we analyze in this paper, finding a good abstraction maybe as difficult as 
proving the invariants of the system. On the other hand, automated abstractions 
such as the ones presented in [HKL+98] are not strong enough to eliminate the 
integer variables in the systems we analyze in this paper. 



3 Symbolic Model Checking 

In model checking, the system to be analyzed is represented as a transition 
system TS = {S,I,R) with a set of states S, a set of initial states ICS, and 
a transition relation R C S x S . The transition system model is never explicitly 
generated in symbolic model checking. For example, BDD-based model checkers 
represent transition relation i? as a set of boolean logic formulas. 

A popular temporal logic for specifying temporal properties of transition 
systems is Computation Tree Logic (CTL) [CES86] which consists of a set of 
temporal operators (the next-state operators EX and AX, the until operators 
EU and AU, the invariant operators EG and AG, and the eventuality operators 
EF and AF) for specifying temporal properties. 

Our goal in model checking a system TS = (S,I,R) and a temporal prop- 
erty p is (we use p to denote its truth set) : 1) either to prove that the system 
TS satisfies the property p by showing that I C p, or 2) to demonstrate a bug 
by finding a state s G / G ~^p, and generating a counter-example path starting 
from s. 

Assume that there exists a representation for sets of states which supports 
tests for equivalence and membership. Then, if we can represent the truth set of 
the temporal property p, and the set of initial states / using this representation, 
we can check the two conditions listed above. If the state space is finite, explicit 
state enumeration would be one such representation. Note that as the state 
space of a concurrent system grows, explicit state enumeration will become more 
expensive since the size of this representation is linearly related to the number of 
states in the set it represents. Unfortunately, state space of a concurrent system 
increases exponentially with the number of variables and concurrent components. 
This state space explosion problem makes a simple implementation of the explicit 
state enumeration infeasible. 

Another approach is to use a symbolic representation for encoding sets of 
states. For example, a logic formula which is semantically interpreted as a set 
of states, can be used as a symbolic representation. Boolean logic formulas 
(stored using the BDD data structure) are the most common symbolic rep- 
resentation used in model checking [BGM+90]. Recently, we used Presburger 
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arithmetic (integer arithmetic without multiplication) formulas for the same 
purpose [BGP97,BGP99], 

Model checking procedures use state space exploration to compute the set 
of states which satisfy a temporal property. Fixpoints corresponding to truth 
sets of temporal formulas can be computed by iteratively aggregating states 
using pre-condition computations (which correspond to the next state operator 
EX). Temporal properties which require more than one fixpoint computation 
can be computed recursively starting from the inner fixpoints and propagating 
the partial results to the outer fixpoints. 

All temporal properties in GTL can be expressed using boolean connectives, 
next state operator EX, and least fixpoints. For example, EFp = . pVEX x. 

The least fixpoint of a monotonic functional can be computed by starting from 
the bottom element (i.e., false = 0) and by iteratively applying the functional 
until a fixpoint is reached. 

Assume that Symbolic is the data type used for encoding sets of states. In 
order to implement a symbolic model checker based on Symbolic data type we 
need the following procedures: 

Symbolic Not(Symbolic) : Given an argument that represents a set p C S', it 
returns a representation for S — p. 

Symbolic And(Symbolic, Symbolic) : Given two arguments representing two 
sets p, <7 C S, it returns a representation for pH q. 

Symbolic Or(Symbolic, Symbolic) : Given two arguments representing two 
sets p, g C S, it returns a representation for p U g. 

Symbolic EX(Symbolic) : Given an argument that represents a set p C S, it 
returns a representation for the set {s | 3s' . s' G p A (s, s') G R}. 

Boolean Equivalent(Symbolic, Symbolic) : Given two arguments represent- 
ing two sets p,q C S, it returns true if p = g, returns false otherwise. 

Using the procedures described above, given a temporal formula, we can com- 
pute its truth set by computing the fixpoint that corresponds to that temporal 
formula. 

The computation of the procedure EX involves computing a relational image. 
Given a set p C S and a relation X C S x S we use A p to denote relational 
image of p under X, i.e., A p is defined as restricting the domain of A to set p, 
and returning the range of the result. Note that we can think of relation A as a 
functional A : 2'^ — > 2‘®. Then, A p denotes the application of the functional A 
to set p. 

Let R~^ denote the inverse of the transition relation R. Then EX p = R~^ p, 
i.e., functional EX corresponds to the inverse of the transition relation R. Hence, 
we can compute the procedure EX using a relational image computation. Most 
model checkers represent transition relation i? in a partitioned form to make the 
relational image computation more efficient [BGL91]. 

Any representation which is able to encode the set of initial states / and the 
set of atomic properties AP, and supports the above functionality can be used 
as a symbolic representation in a model checker. We call such a representation 
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an adequate language for model checking [KMM+97]. For example, for finite- 
state systems, boolean logic would be one such representation. It is possible 
to implement procedures for negation, conjunction, disjunction and equivalence 
checking of boolean logic formulas. If we can represent the transition relation R 
as a boolean logic formula, then relational image computation R~^ p can be 
computed by conjuncting the formula representing R~^ and the formula repre- 
senting p, and then eliminating the variables in the domain of the resulting rela- 
tion using existential quantifier elimination. BDDs are an efficient data structure 
for representing boolean logic formulas, and they support all the functionality 
mentioned above [Bry86]. They have been successfully used for model check- 
ing [BCM’^90,McM93]. However, they can not encode infinite variable domains. 

Recently, we developed a model checker for systems with unbounded inte- 
ger variables using Presburger arithmetic formulas as a symbolic representa- 
tion [BGP97]. There are effective procedures for manipulating Presburger for- 
mulas which support the above functionality — for example Omega Library im- 
plements a set of such procedures [KMP+95]. We implemented a model checker 
using Omega Library as our symbolic manipulator. However, model checking 
computations become undecidable for infinite domains, i.e., the fixpoint compu- 
tations corresponding to temporal properties may not always converge for infinite 
domains. We addressed this issue in [BGP99] using conservative approximations. 



4 Example Concurrent Systems 

The examples we use in this paper have the following characteristics: 1) they 
are all asynchronous concurrent systems, and 2) they all use shared integer 
variables to control their synchronization. We think this type of systems are 
especially suitable for constraint-based representations. Most of our examples 
are from [And91]. 

We represent each concurrent system with a set of events, where each event 
is considered atomic (Fig. 1). The state of a program is determined by the values 
of its data and control variables. If a variable v is used in an event, then the 
symbol v' denotes the new value of v after the action is taken. If v' is not 
mentioned in an event, then we assume that its value is not altered by that 
event. Each event specification defines a transition relation over the Gartesian 
product of the domains of the variables in the system. The transition relation of 
the overall concurrent system is defined as the union of the transition relations 
of all events in the system. 

Bakery algorithm, shown in Fig. 1 for two processes, is a mutual exclusion 
algorithm. The algorithm we present above is the coarse grain solution [And91] 
which can be further refined to implement without fetch-and-add instructions. 

In Fig. 1 we show a solution to sleeping barber problem [And91]. The barber 
allows a new customer into the shop with the event Cnexti ■ The customer gets a 
chair by calling the event Chaircuti (as long as their is an available chair). Then 
the barber starts the haircut with event Cnext^ ■ When the haircut is finished the 
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Program: Bakery 

Data Variables: a, b: positive integer 

Control Variables: pci : {Ti,Wi,Ci}, pc2 : {T2,1V2,C2} 

Initial Condition: a = b = 0 A pci = Ti A pc2 = T2 
Events: 

cti : pci =T\ A pc'i = Wi Aa' = b + 1 
ewi ■ pci = Wi A{a<b\/b = 0 )A pc'i = Ci 
eci : pci — Cl A pc'i = Ti A a' = 0 
6t2 : PC2 = T2 A pc'2 = W2 Ah' = a + 1 
ew2 ’■ PC2 = W2 A(ti<oVa = 0 )A pc'2 = C2 
eca : PC2 = C2 A pc'2 = T2 A b' = 0 
Program: Barber 

Data Variables: cinchair, cleave, bavail, hbusy, bdone: positive integer 
Control Variables: pci : {1,2}, pc2 : {1,2} pcs : {1,2} 

Initial Condition: cinchair = cleave = bavail = hbusy = bdone — 0 
Apci = PC2 = PC3 — 1 

Events: 

ehaircut-i ’■ pci = 1 A pc'i = 2 A ciuchair < bavail A cinchair' = cinchair + 1 

Chaircut2 ’■ PCi ~ 2 A pc'i = 1 A clcavc < bdone A cleave' = cleave + 1 

enexti : PC2 = 1 A pc'2 = 2 A bavail' = bavail + 1 

enext2 ’■ PC2 = 2 A pc'2 = 1 A bbusy < cinchair A bbusy' — bbusy + 1 

Cfinishi '■ PC3 = 1 A pc'3 = 2 A bdone < bbusy A bdone' = bdone + 1 

e finish 2 ’■ PC3 = 2 A pc'3 = 1 A bdone = cleave 

Program: Readers- Writers 

Data Variables: nr, nw: positive integer 

Initial Condition: nr = nw = 0 

Events: 

Creader — enter • nW — 0 A nr — nr 1 
Creader — exit • nr ^ 0 A nr — nr 1 
Cmriter-enter : nr ~ 0 A nw = 0 A nw' = nw + 1 
Cwriter — exit • nW ^ 0 A nW — nW 1 
Program: Bounded-Buffer 

Parameterized Constant: size : positive integer 

Data Variables: available, produced, consumed: positive integer 

Initial Condition: produced = consumed = 0 A available = size 

Events: 

Cproduce '■ 0 < available A produced' = produced -|- 1 A available' = available — 1 
Cconsume '■ available < size A consumed' = consumed + 1 
Aavailable' = available + 1 
Program: Circular-Queue 

Parameterized Constant: size : positive integer 

Data Variables: occupied, head, tail, produced, consumed: positive integer 
Initial Condition: occupied = head — tail — produced = consumed = 0 

Events: 

Cproduce '■ occupicd < sizc A occupicd' = occupied + 1 A produced' = produced + 1 
A{tail = size A tail' = 0 V tail < size A tail' = tail + 1) 

Cconsume '■ occupicd > 0 A occupicd' = occupicd — 1 A consumed' = consumed + 1 
A(head = size A head' = 0 V head < size A head' = head -I- 1) 

Fig. 1. Example concurrent systems used in the experiments 
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barber executes Cdonei, and waits {edone 2 ) till the customer leaves by executing 
the event Cjiaircut^ • 

A well-known algorithm for readers-writers problem is also presented in 
Fig. 1. The invariant of the readers-writers problem states that at any time 
there would be either no writers accessing the database or no readers, and the 
number of writers should never be more than one. 

Two algorithms given in Fig. 1 present bounded-buffer implementations. 
Both these systems have a parameterized constant size which specifies the size 
of the buffer. Since size is parameterized the systems given above should be 
correct for any value of size. 

In Table 1 we list the invariants the systems presented above have to satisfy. 



Table 1. List of problem instances used in the experiments 



Problem Instance 


Property 


BAKERY 


AG(^(pci = Ci Apc 2 = C 2 )) 


BARBER 


AG{cinchair > cleave A havail > bbusy > bdone 
A cinchair < bavail A bbusy < cinchair A cleave < bdone) 


BARBER- 1 


AG{cinchair > cleave A bavail > bbusy > bdone) 


BARBER- 2 


AG{cinchair < bavail A bbusy < cinchair) 


BARBER- 3 


AG{cleave < bdone) 


READERS-WRITERS 


AG( (nr = 0 V nw = 0) A nw < 1) 


BOUNDED-BUFFER 


AG(produced — consumed = size — available 
A 0 < available < size) 


BOUNDED-BUFFER- 1 


AGijproduced — consumed = size — available) 


BOUNDED-BUFFER-2 


AG(0 < available < size) 


BOUNDED-BUFFER-3 


AG(0 < produced — consumed < size) 


CIRCULAR-QUEUE 


AG(0 < produced — consumed < size 
A produced — consumed = occupied) 


CIRCULAR-QUEUE- 1 


AG(0 < produced — consumed < size) 


circular-queue-2 


AGijproduced — consumed = occupied) 



5 Experimental Evaluation 

We translated the examples given in Fig. 1 to the SMV input language. For 
each concurrent process we used the process declaration in SMV which sup- 
ports asynchronous composition. SMV converts all integer variables to a binary 
representation since it is a BDD-based model checker. We used an uninitialized 
variable that always preserves its value to represent the parameterized constant 
size in the bounded-buffer and circular-queue systems. 

Our omega library based model checker accepts a Presburger arithmetic for- 
mula for each event in the input system. It forms the global transition relation 
by combining these formulas disjunctively. It uses asynchronous composition to 
combine two concurrent components. It is not efficient to map variables with 
small domains (such as program counters) to integer variables. So, for the exam- 



BDD vs. Constraint-Based Model Checking 449 



pies with control variables we used control point partitioning to eliminate the 
control variables [BGP99] . 

To compare the performances of SMV and OMC (Omega library Model 
Checker) we assigned a finite domain to each integer variable. We generated 
16 different instances for each concurrent system by restricting the integer vari- 
ables to different ranges. We started with a range of 0 < i < 2^ for each integer 
variable i (which makes it possible to represent each variable i with 3 boolean 
variables in SMV) and increased it until 0 < i < 2^® (which requires 26 boolean 
variables for each integer variable). 

In Figs. 2 and 3 we show the performances of both SMV and OMC in terms of 
execution time and memory usage. We ran all our experiments on an Intel Pen- 
tium III PC (500MHz, 128 MByte main memory) running Solaris. Each graph 
shows experiments on one concurrent system. Data points in each individual 
graph is generated by only changing the range of values that integer variables 
are allowed to take. The x axis in these graphs show the number of boolean 
variables required for the binary encoding of each integer variable (which ranged 
from 3 to 26 in our experiments). So, for each point in the graph, the range 
of each integer variable i in the concurrent system verified in that particular 
experiment is 0 < f < 2®. 

In our initial experiments we observed that the execution time and the mem- 
ory usage of SMV increases exponentially with the number of boolean variables 
required for the binary encoding of each integer variable (which corresponds 
to a linear increase in the size of the domains of the integer variables). This 
exponential increase can be observed in Figs. 2 and 3. 

The worst-case complexity of the BDD representation is exponential in the 
number of boolean variables it represents. The exponential increase in execution 
time and memory usage of SMV is a realization of this worst-case complexity. 
However, as observed by Chan et al. [CAB+98] and Yang et al. [YMW97] this 
is because of the inefficient representation of integer variables in SMV and can 
be improved using a better variable ordering. 

BDD representation is very sensitive to variable ordering [Bry86]. In SMV, 
given two integer variables i and j, all the boolean variables representing vari- 
able i either precede all the boolean variables representing j or vice versa. With 
such an ordering the BDD representing a constraint such as i = j has exponen- 
tial size in the number of boolean variables. However, if the order of boolean 
variables representing i and j are interleaved the same constraint has a linear 
BDD representation [CAB+98]. William Chan developed macros which generate 
such an interleaved order for SMV. Using his macros, we tested the SMV system 
again for the examples given in Fig. 1. As seen in Figs. 2 and 3, with this variable 
ordering the execution time and the memory usage of SMV increases linearly 
with the number of boolean variables required for the binary encoding of each 
integer variable (which corresponds to a logarithmic increase in the size of the 
domains of the integer variables). 

For the examples shown in Figs. 2 and 3 the performance of OMC stays 
constant with respect to increasing variable domains. This is because of the fact 
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that, for these examples, the size of the fixpoint iterates and the number of fix- 
point iterations stay constant with respect to increasing variable domains for the 
constraint-based model checker OMC. Note that, changing the maximum value 
that an integer variable can take from one integer constant to another integer 
constant does not increase the size of the constraint representation. Also, for the 
examples shown in Figures 2 and 3, the model checking procedure converges in 
a constant number of fixpoint iterations which is independent of the size of the 
domains of the variables. However, this may not always be the case. For example, 
for properties bounded-buffer-3 and CIRCULAR-QUEUE-1 (Table 1) the num- 
ber of fixpoint iterations depends on the size of the domain of the parameterized 
constant size. 

Figure 2 shows the performances of SMV and OMC on verification of both 
two and three process implementations of the bakery algorithm with respect 
to the property bakery shown in Table 1. The performance of both SMV and 
OMC deteriorate significantly if the number of processes is increased. However, 
the cost of constraint-based model checking seems to increase more significantly 
compared to HDD-based model checking. 

Based on Figs. 2 and 3 OMC outperforms SMV without interleaved variable 
ordering if the integer variables require more than 6 boolean variables to encode. 
If interleaved variable ordering [CAB+98] is used, for bakery with two processes 
and BARBER, the execution time of OMC is better than SMV if 18 and 14 boolean 
variables are used, respectively. The memory usage of OMC is always better than 
SMV in these cases. For the bakery with three processes SMV with interleaved 
variable ordering always outperforms OMC both in execution time and memory 
usage. For readers-writers, bounded-buffer and circular-queue, OMC 
always outperforms SMV with interleaved variable ordering both in terms of 
execution time and memory usage. 

Note that both bakery and barber algorithms given in Fig. 1 use variables 
with finite domains (pci,pc 2 ,pc 3 ). Presence of such variables increases the cost 
of the constraint based representation since OMC partitions the state space to 
eliminate them. We believe that this is why the relative performance of OMC is 
not as good for these examples as it is for readers-writers, bounded-buffer and 
circular-queue. A composite approach which combines the BDD and constraint- 
based representations can be used in such cases [BGL98] . 

In Table 2 we show the performance of SMV (with interleaved variable or- 
dering) and OMC for the problem instances given in Table 1 where each integer 
variable i is restricted to the range 0 < i < 1024 (we also restricted the param- 
eterized constant size to 0 < size < 16). For most of these instances SMV and 
OMC have comparable performances. However for the bakery the increase in 
execution time and memory usage of OMC with respect to increasing number 
of processes is significantly higher compared to SMV. For 4 processes OMC did 
not converge in one hour (we indicate this with | in Table 2). 

Another shortcoming of OMC is demonstrated in the verification of prop- 
erties bounded-buffer-3 and circular-queue- 1 shown in Table 1. None of 
the fixpoint computations for these properties converged (in an hour) when we 



BDD vs. Constraint-Based Model Checking 451 



Table 2. Experiments where each integer variable i is restricted to 0 < i < 1024. 
In bounded-buffer and circular-queue instances the parameterized constant size 
is restricted to 0 < size < 16 (| denotes that the fixpoint computations did not 
converge) 



Problem Instance 


SMV (with Chan’s 
variable ordering) 


OMC 


Execution 

Time 

(seconds) 


Memory 

Usage 

(Kbytes) 


Execution 

Time 

(seconds) 


Memory 

Usage 

(Kbytes) 


BAKERY (2 processes) 


0.12 


1507 


0.29 


655 


BAKERY (3 processes) 


0.82 


2228 


7.32 


12165 


BAKERY (4 processes) 


19.15 


9110 


T 


T 


BARBER 


0.40 


2425 


0.55 


1458 


BARBER- 1 


0.53 


2490 


15.37 


23101 


BARBER-2 


0.35 


2228 


0.29 


926 


BARBER-3 


0.35 


2228 


0.15 


655 


READERS-WRITERS 


0.03 


1245 


0.05 


295 


BOUNDED-BUEEER 


0.28 


2163 


0.08 


238 


BOUNDED-BUFFER-l 


0.27 


2228 


0.05 


188 


BOUNDED-BUFFER-2 


0.26 


2163 


0.04 


147 


BOUNDED-BUFFER-3 


163.30 


3080 


T 


T 


CIRCULAR-QUEUE 


1.08 


3408 


0.10 


377 


CIRCULAR-QUEUE-1 


1228.45 


6357 


T 


T 


circular-queue-2 


1.04 


3342 


0.07 


328 



tried to verify them using OMC. This is the price we pay for using an expressive 
representation such as constraints which have higher worst case complexity than 
BDD manipulation. For the properties bounded-buffer-3 and CIRCULAR- 
QUEUE-1, the number of fixpoint iterations depend on the size of the domain of 
the parameterized constant size. For these properties OMC does not converge 
even for the small domain 0 < size < 16. Note that, for these cases BDD based 
model checking is not very efficient either (even with interleaved variable order- 
ing). We think that for such cases using conservative approximation techniques 
would be helpful [BGP99]. 



6 Conclusions 

The experimental results we obtained in this work suggests that constraint- 
based model checking can be more efficient than BDD-based model checking 
for verification of asynchronous concurrent systems with finite but large integer 
domains. This supports our view that constraint-based model checking is not 
limited to infinite-state systems but can also be useful for verification of systems 
with large integer domains. 
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Execution Times: Bakery (2 Processes) 



Memory Usage; Bakery (2 Processes) 
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Fig. 2. Execution times and memory usage for OMC, SMV, and SMV with 
Chan’s variable ordering (smv+co) in verification of bakery, barber and 
READERS-WRITERS 
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Execution Times: Bounded-Buffer (size<8) 



Memory Usage: Bounded-Buffer (size<8) 
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In the future we would like to compare the performance of constraint-based 
model checking with the performance of word- level model checking [CZ95]. We 
are also planning to investigate the performance of our composite model checking 
approach [BGL98] with respect to BDD-based representations. 

We would also like to investigate the complexity analysis of both BDD and 
constraint-based model checking for the type of systems analyzed in this paper. 
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Abstract In this contribution we introduce GenGEd, an environment 
which is used to interactively specify and generate syntax-directed editors 
for visual languages. 

In analogy to textual languages a visual language is specified by both, an 
alphabet and a grammar. Hence, the GenGEd environment provides an 
Alphabet Editor and a Grammar Editor, respectively. The grammar rules 
defined using the Grammar Editor specify not only language-generating 
rules but additionally the editing commands of the Graphic Editor for 
the specihc visual language. The language-specihc Graphic Editor then 
can be used in various environments to allow for syntax-directed drawing 
of diagrams. 



1 Introduction 

Visual languages are everywhere! Since often a graphical description of a problem 
or a model provides more readability and takes less space than a textual one, 
diagrams are used to visualize complex facts. To support the communication 
within larger communities, diagrams need some syntax and semantics to be 
understood by all members. In analogy to textual languages (natural but also 
formal ones) we can summarize syntactical and even semantical information in 
diagrams. 

The graphical capabilities of today’s computer systems permit the construc- 
tion of diagrams completely with a computer, like it is done in architecture and 
electrical engineering. Nowadays, diagrams are additionally used in computer 
science for modeling and programming of complex systems. Such diagrams con- 
cern visual languages. It depends on the purpose of the visual language whether 
it is called visual modeling language or visual programming language. Visual 
modeling languages used for software engineering are, e.g., the Unified Modeling 
Language (UML) [Rat98] and statecharts [Har87]. Without a doubt, there are 
needs for editors to draw diagrams in those languages. Furthermore, in order 
to state about software quality and correctness it is important to draw correct^ 
diagrams. 

^ Diagrams can be correct with respect to some formal specification. 
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The problem with existing tools and editors for, e.g., software development 
(Rational Rose, Statemate, etc.) and also with so-called visual programming 
environments (Visual Basic, Delphi, etc.) is that the visual means are tightly 
integrated in the visual environment. Re-implementation is necessary whenever 
the concepts of a visual language or the basic visual means change. The GenGEd 
environment [Bar00,BNS00] on the other hand permits the easy and interactive 
definition of arbitrary Graphic Editors for visual languages^. 

There are two major ways to build an editor for a visual language according 
to some specification: The first way is to take a simple graphical editor with 
which some kind of diagrams based on graphical primitives (like line, rectangle, 
circle etc.) can be drawn. This can be either some existing vector graphics editor 
or a slightly modified editor adapted to the symbols we use in our language. To 
check for syntactical correctness of a drawn diagram we will have to do some 
scanning- and parsing-like operations on the diagram according to a graphical 
syntax given in some way. We will denote those editors as freehand editors. The 
second way is to provide the user drawing a diagram with only the operations 
(insert a symbol, remove a symbol) with which he or she is “forced” to draw 
syntactically correct diagrams. That circumvents the syntax checking but adds 
more restriction to the user of such an editor. These editors will be called syntax- 
directed editors. 

The path we choose in the GenGEd environment is the second one, i.e., we 
consider syntax-directed editors. We do this because we can provide the designer 
of a visual language with powerful means to write grammars - in analogy to for- 
mal language grammars - with which we then generate a Graphic Editor for this 
language. So our environment can be used to specify existing visual languages like 
graph-like class diagrams occurring in the UML or box-like Nassi-Shneiderman 
diagrams [NS73], but also to construct completely new visual languages from 
scratch. 

This presentation is built as follows: We start by giving an informal definition 
about the concepts of visual language specifications underlying the GenGEd 
environment in section 2. For illustrational reasons we use some features of the 
well-known visual language of class diagrams [Rat98] . In section 3 we introduce 
the GenGEd environment which is elucidated by screenshots. Some related 
approaches concerned in generating editors from visual language definitions will 
be mentioned in section 4. Concluding remarks will be made in section 5. 



2 Concepts of Visual Language Specifications 



When we take a closer look on two-dimensional diagrams following a certain 
specification there are two major parts we have to consider. On one hand we 
have some graphical symbols like classes or associations in an UML class diagram 
(see fig. 1 (a)). On the other hand there are spatial relations such that a symbol 

^ Research is partially supported by the German Research Gouncil (DFG), and the 
ESPRIT Basic Research Working Group APPLIGRAPH 
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must be aligned with another one or, more precisely, that an association arrow 
must start at the border of a class symbol (see fig. 1 (b)). 
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Figurel. Symbols (a) and connections (b) of class diagrams 

In formal textual languages, relations between symbols like “follows” are not 
described explicitly in an alphabet. However, in analogy to formal languages, 
for a visual language we first need an alphabet over which sentences, namely 
diagrams, can be constructed. In the GenGEd approach, an alphabet keeps all 
the information about the graphical symbols and furthermore, the possible rela- 
tions between symbols. We will denote those relations as connections because we 
consider not only spatial relations like the anchorBorder constraint in figure 1 
(b) but additionally the corresponding underlying structural relationships from: 
Association — > Class. These structural relationships are used to express the 
logical meaning of a diagram. E.g., according to the UML specification, it is not 
allowed that an association symbol is “dangling” as illustrated in figure 1 (b). 
The end of the association arrow has to be connected with a class symbol, too. 
In order to avoid such incorrect constellations, a second structural relationship 
like to : Association — > Class has to be defined together with suitable spatial 
relations. Both connections (from, to) then ensure that an association symbol 
is always connected with class symbols. 

It is not sufficient to construct diagrams from an alphabet only. And addi- 
tionally, it is not sufficient to generate a specific Graphic Editor where one can 
arbitrarily insert and remove symbols and connections. In this case there will 
be diagrams with illegal syntactical constellations. Like in formal languages, we 
have to give some rules to define insertion and deletion of symbols and implicitly 
the corresponding connections. The rules together with a start diagram (which 
is analogous to a start sentence in formal languages) form a grammar. The gram- 
mar rules are used as editing operations on the start diagram^ - so we will not 
only give language-generating rules, but also editing rules allowing for changing 
or deleting symbols and connections in a language-specific Graphic Editor. 

The alphabet and the grammar of a visual language establishes a visual lan- 
guage specification over that diagrams can be edited. These concepts are based 
on the well-established theory of algebraic graph transformation that is fully 
described in [BarOO]. In the following we do informally explain these concepts 
which are implemented in the GenGEd environment. 

® In fact this will be done in the GenGEd environment later on. 
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2.1 The Alphabet 

An alphabet comprises a set of symbols and a set of connections. From the 
graphical point of view, symbols are expressed by sets of graphical primitives, 
and connections are expressed by sets of graphical constraints. 

Primitives Graphical primitives are simple graphics like lines, rectangles, cir- 
cles, etc. They all have a location in a two-dimensional space and some properties 
like width, height, color, starting point etc. 

Constraints Graphical constraints denote spatial relations between graphics. 
One constraint may concern to one or more graphics. A constraint is given by 
a set of equations and inequalities over the graphic’s properties. Some examples 
for constraints are given in figure 2. A graphically correct diagram is a diagram 
where all constraints are satisfied. So we have to make sure that the symbol’s 
properties like size and location are chosen in a way that the corresponding 
constraints are satisfied. This can be achieved using a constraint solver. 
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Figure2. Gonstraint examples 



Symbols A symbol consists of a certain symbol name and a symbol graphic. 
This graphic is a grouping of several graphical primitives. The grouping is defined 
by graphical constraints like that of figure 2. Nevertheless, each symbol graphic 
consists of a box enclosing the corresponding primitives. This box can be treated 
like a common graphical primitive. 

Connections A connection is defined between two symbols with respect to the 
symbol names and the symbol graphics. According to the symbol names it is 
a directed connection where one symbol name is in the source and the other 
one is in the target of the connection (see fig. 1 (b)). Note that due to the 
underlying theory [BarOO] the insertion of a directed connection on the instance 
level requires for a symbol that is in the source of the connection the presence 
of a symbol that is in the target such that the connection is correctly defined. 
We will call this property “structural correctness”. In addition to a directed 
connection, according to the structural relationship a connection is defined by a 
set of constraints between the involved symbol graphics. 

Data Attributes Some symbols need attributes we cannot handle in a purely 
graphical way. Such attributes are e.g., class names or association cardinalities 
as shown in figure 1. Data attributes can be strings, integers, lists or any other 
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well-defined^ datatype. Every data type has a set of operations (like append; 
StringList String — > StringList) which can be used to code attribute 
changes (renaming, increasing counters and the like) into our rules. This goes 
beyond the capabilities of graphic editors which allow only the use and the sim- 
ple renaming of strings. Nevertheless, each datatype must have a certain layout 
that depends on the specific datatype. For strings, e.g., the layout information 
includes text size and text font. 



2.2 The Grammar 

With the means to describe the graphical structure of diagrams we will now 
add the concepts used to construct syntactically correct diagrams. This is made 
possible by the grammar that is based on the language-specific alphabet. The 
grammar is defined by a start diagram and a set of rules. The rules are not re- 
stricted to be context-free; they are context-sensitive and may be enhanced with 
some application conditions. Moreover, the rules define the editing commands 
of the aimed Graphic Editor that is generated from the visual language specifi- 
cation consisting of an alphabet and a grammar. These rules can be applied to 
a given start diagram. 

Start diagram A start diagram comprises symbols and connections that are 
uniquely instantiated from the alphabet. Due to the alphabet, each symbol con- 
sists of a certain symbol name and a symbol graphic, probably some symbol 
constraints. Each connection is defined by a directed connection between the 
involved symbol names and some constraints between the corresponding symbol 
graphics. 

Rules and Rule Application A visual language rule consists mainly of a left 
hand side (LHS) and a right hand side (RHS) . A mapping of symbols from the 
LHS to the RHS (see upper part of fig. 3) indicates that the mapped symbols 
are preserved when the rule is applied to a given diagram. The connections are 
mapped implicitly. 

Applying a rule to a given diagram, the symbols of the LHS have to be 
mapped to the symbols of the diagram we want to transform. This mapping 
is called match. The connections are mapped implicitly if there are some. This 
implicit mapping is called “match completion” . 

The RHS of a rule contains another diagram comprising all the elements 
which persist through the transformation (namely those which are mapped from 
the left to the right) and all elements which are added through the transforma- 
tion. The elements (symbols and connections) which appear in the LHS but not 
in the RHS will be deleted from the diagram where the rule is applied to. 

Figure 3 illustrates the application of the rule that allows for the insertion 
of an association symbol. The two class symbols of its LHS are mapped to the 

^ Well-defined in GenGEd means that the attribute can be handled like a “black box” 
which can be drawn somewhere in the diagram. 
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Figures. Example rule InsertAssociation and its application to a diagram 



class symbols of the diagram. Due to the mappings, the transformation process 
inserts the association symbol between these two class symbols. Note that it is 
also conceivable to map both class symbols of the rule’s LHS to one class symbol 
of the diagram. 



Negative Application Conditions Rules like that of figure 3 are sometimes 
not sufficient to describe the complete syntax of a visual language and the editing 
commands of the aimed Graphic Editor. Therefore, rules can be enhanced with 
negative application conditions (NACs) expressing that some constellations must 
not occur in the diagram where the rule is applied to. So one of our rules consists 
of a LHS, a RHS, a mapping from the LHS to the RHS and a (possibly empty) 
set of NACs, each one with a mapping from the LHS into the NAG diagram. 
The mappings into the NACs deliver the connection for the conditions. 

In order to illustrate NACs let us have a look to figure 4 showing the rule for 
deleting a class symbol. This rule is enhanced with two NACs stating that the 
class symbol that is to be deleted is not connected with an association symbol, 
neither by the structural from connection nor by the to connection. For the 
application of a rule with NACs, we have to check whether one of the NACs can 
be satisfied after matching the LHS’ elements to a diagram. If this is the case, 
the application will not take place. 
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Figure4. Rule with negative application conditions 
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Assuming the rule of figure 4 without any NACs. We have to mention that the 
application of such a rule would lead to the deletion of all adherent association 
symbols due to the from and the to connections defined for the alphabet. This 
behavior is probably not desired which is the reason for defining the NACS. 



Data Attributes and Rule Parameters Until now we have presented rules 
without data attributes for symbols, so in the examples there have been no 
association cardinalities nor class names. Data attributes may appear in the LHS, 
RHS and in the NACs, namely as variables, constants or complex expressions 
that are defined for the corresponding datatypes. In contrast to the rules, a 
diagram where rules can be applied to, comprises constants only. 

Rule parameters allow for the external definition of data attributes. A rule 
parameter consists usually of a variable and a datatype. The rule is applied with 
user-defined values for the rule parameters. Then, the variables take the role 
of matched variables, i.e., they are matched with a constant. One example is 
given by figure 5 showing the rule for the insertion of a class symbol. The rule 
comprises a rule parameter with the variable cn of type String. This variable 
occurs in the NAC as well as in the RHS of the rule. Applying this rule, the 
user is asked to define a class name for the variable that is substituted by the 
name. Hence, the NAC states that the class symbol with this name must not be 
existent in the diagram where the rule is applied to. 

InsertClass (cn: String) 
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Figures. Rule for inserting a class name 

An example for complex expressions is given by figure 6. Each class symbol 
comprises a method list (modeled by the datatype String List) that is connected 
to the lower rectangle of a class symbol. The rule that allows for adding a method 
to the method list of a class symbol is given by figure 6. It contains a variable 
for the user-defined method in its rule parameter. In its LHS the variable for 
the method list is illustrated together with the datatype. This variable together 
with the rule parameter variable are part of the available operation add denoted 
in the RHS of the rule. The operation is executed when the rule is to be applied 
to a given diagram. Therefore, the user is forced to define a concrete method as 
described above. 
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FigureG. Rule for adding methods to the method list 
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Until now we have suggested the most important concepts for visual language 
specifications and editing of diagrams. These concepts are implemented in the 
GenGEd environment that is explained in the following section. 

3 The GenGEd Environment 

The GenGEd environment comprises two major components: the Alphabet Ed- 
itor and the Grammar Editor (see fig. 7), each editor corresponds to the respec- 
tive part of the visual language, namely the alphabet and the grammar. To assure 
the graphically correct drawing of diagrams both editors use the constraint solver 
ParGon [Gri96]. The transformation of diagrams via rule application is done 
by the graph transformation system Agg [TER99]. 




Figure?. Overview about the GenGEd environment 

Simply speaking, the specification of a Graphic Editor for a visual language 
using GenGEd works like this: 

1. We define the symbols and connections of a specific visual language using 
the Alphabet Editor. 

2. The final alphabet is taken as an input to the Grammar Editor which then 
generates simple insertion/deletion rules. Those rules are to be used (in the 
notion of editor commands) to construct more complex visual language rules 
and to define a start diagram for the visual language. 

3. The final visual language specification, consisting of the alphabet, the visual 
language rules and the start diagram, are then fed into a parameterized 
Graphic Editor. The user-defined editing commands of this editor (“insert”, 
“delete” etc.) are built from the grammar rules. 

The GenGEd environment is implemented in Java, also is the Agg system. 
Because the ParCon constraint solver - implemented in Objective-C - is only 
available for Linux and Solaris, GenGEd runs only on these two platforms. A 
prototype is available for download at 

http : //cs . tu-berlin . de/~genged. 
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3.1 The Alphabet Editor 

The Alphabet Editor is a bundling of two minor editors - the Symbol Editor (see 
fig. 9) and the Connection Editor (see fig. 10). The Alphabet and Connection 
Editors feature the usual GUI elements like a menu and toolbar to add symbols, 
data attributes, connections and constraints and a statusbar to display various 
useful information. The appearance of the editors is the same: on the left side 
there is a structure display of the objects we work on showing primitives and 
constraints. On the right there is a graphical display of the selected symbol 
or connection. This graphical display is already constraint-based, so each added 
constraint will be checked for solvability and will be visualized immediately after 
creation. Both editors use a further subcomponent, the Constraint Editor. 



Constraint Editor The constraint editor as shown in figure 8 is available 
in both, the Symbol Editor as well as the Connection Editor. In both editors, 
constraints can be defined on arbitrary primitives. 




Figures. The Constraint Editor 

The constraint solver ParCon that is used for constraint solving permits only 
the definition of very low level constraints. We have enhanced these constraints 
by a high-level constraint language (HLCL). This language features extensibility, 
types over the graphical primitives and built-in definitions for user dialogs. Here 
is an example for an above-Constraint taken from the extendable HLC database: 

constraint Above (Base a. Base b) { 

DialogCa, "English", "Objectl"); 

DialogCa, "Deutsch" , "Objektl"); 

DialogCb, "English", "0bject2"); 

DialogCb, "Deutsch", "0bjekt2"); 

DescriptionC'English" , "Objectl lies above object2."); 

DescriptionC'Deutsch" , "Objektl liegt V'fufber 0bjekt2."); 

a.lt.y < b.lt.y - a.h; I 

The graphical attributes of the primitives being part of the constraint (width, 
height, x/y-location, etc.) can be accessed using a path notation. The HLCL is 
easily editable and extendable by editing a simple text file. 
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All constraints we define in one of the GenGEd Alphabet Editors are imme- 
diately applied to the symbol(s). When the user scales or moves single objects 
in the display all constraints are automatically solved, which leads possibly to 
a new arrangement of the whole graphic in the display. Constraints which are 
unsolvable will be marked for overworking. 



Symbol Editor The Symbol Editor is shown in figure 9. It works similar to 
well-known vector graphic editors except that the grouping of symbols is han- 
dled as described in section 2 - using constraints to connect the primitives in 
a graphic. Implemented primitives available are lines, polylines, bezier curves, 
rectangles, ellipses, images (GIF/ JPEG), text, invisible boxes (which can serve 
as placeholders) and connection points which can be used to define complex 
connections in the Connection Editor. The primitives’ properties like color, line 
width or text properties can be edited. 




Figure9. The Alphabet Editor with activated Symbol Editor 



Data attributes appear as independent graphical objects. From the constraint 
view they are just “boxes with something in it” . Each datatype is implemented 
by a unique Java class. Similar to a JavaBean, the datatype class has to provide 
methods for drawing the attributes and for changing the properties (like text 
font, text size or, for a list of strings, the arrangement of text elements) either 
interactively (using an editing dialog) or by calling a changing method. Other 
methods can be used to build complex Java expressions which will be evaluated 
during rule application (see section 3.2). 

Currently implemented are the classes StringDT, StringListDT, IntegerDT 
and FloatDT. Using the given interface for datatype classes and the existing 
implementations as templates, the designer of a visual language may add own 
datatype classes. 



Connection Editor Concerning the constraint definitions, the Connection Ed- 
itor as illustrated in figure 10 works in just the same way as the Symbol Editor. 
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In contrast to the Symbol Editor, we can select any two symbols as source and 
target of the connection that is to be defined. Again the Constraint Editor is 
used to define constraints between the primitives of the involved symbol graph- 
ics. Note that the connection according to the structural relationship connects 
two symbols (namely the symbol names). In contrast to the concepts, in the 
current implementation the connection constraints can be defined between the 
primitives only, and not between the boxes enclosing the symbol graphics. 
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FigurelO. The Alphabet Editor with activated Connection Editor 

3.2 The Grammar Editor 

The behavior of the Grammar Editor (see Fig. 11) is slightly different from the 
Alphabet Editor because we use instances of the already defined symbols and 
connections to generate simple editing rules. When we start the specification of 
a new visual language grammar, we are first asked to give an alphabet. 



Simple Rules and Structural Correctness From the alphabet, some simple 
rules are generated that are the editing commands of the grammar editor. These 
rules reflect the structure of the alphabet in the sense that they are “struc- 
turally correct” . This property has been described in section 2 when we talked 
about connections. This means that on the one hand every single rule diagram is 
structurally correct and that on the other hand every rule does a ’’‘structurally 
correct”’ transformation, i.e. correct diagrams are transformed into correct dia- 
grams. An example for a generated rule InsertAssociation is given in figure 3. 
Note that some of these automatically generated rules may be already a rule of 
the intended grammar. 



Data Attributes and Rule Parameters For the data attribute part of the 
visual language specification we have means to define rule parameters as well 
as to define and change the expressions for the transformation of datatypes. 
Because of the data attributes belonging to Java classes, the attribute expressions 
depicted in section 2 are in fact Java expressions which are evaluated to get an 
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object of the corresponding data attribute class. For example, the expression on 
the right hand side in figure 6 will look like this: methods . append (m) . Applying 
this rule to a given diagram, the user is first asked to match the class symbol of 
the rule’s LHS to one class symbol in the diagram. Then, the editor window for 
the data attribute StringDT (the rule parameter) will pop up. When the user 
has given a value for the parameter, the expression on the RHS will be evaluated 
during transformation. In this example, the user-defined method is added to the 
method list of the class symbol. 

The Graphical User Interface The Grammar Editor is shown in figure 11. 
On the left hand side there is a structure view of the grammar which contains 
all the names of the automatically generated rules, the start diagram and the 
rules we build using the Grammar Editor. The names of NAGs which may occur 
in a rule are written below the rule names. On the right hand side we have two 
parts: The upper part shows the LHS and RHS of a rule which will be used 
for transformation. The NAGs (selected in the structure view) can be displayed, 
too. The lower part is the work display. Here we built the LHS and RHS (or 
LHS and a NAG respectively) of a new rule, add mappings between the two rule 
sides and edit the rule parameters. 




Figurell. The Grammar Editor 

There are two toolbars: The main toolbar (below the menu) is used to add and 
delete rules and NAGs and to provide save/load and other main functionality. 
Furthermore, the main toolbar is used to define a match from the rule which is 
to be applied onto one of the work diagrams and to trigger the transformation. 
The smaller toolbar (in the work display) provides functionality to add/remove 
mappings in the work rule and to edit the rule parameters. 

Because the graphical displays which are used in the Grammar Editor are de- 
rived from those in the Alphabet Editor, they provide constraint solving, moving 
and scaling of symbols and also single graphical primitives in the same fashion. 
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3.3 Generating a Graphic Editor 

The final step is to export a set of rules and a start diagram into a visual 
language grammar®. Then, the Graphic Editor that is a parameterized editor 
takes this grammar and uses the grammar rules to provide the language-specific 
editing commands. The Graphic Editor for our simple class diagram language is 
is illustrated in figure 12. 




Figurel2. A Graphic Editor for simple class diagrams 



In the current implementation, the Graphic Editor allows for syntax-directed 
editing only. Nevertheless, each edited diagram comprises two levels of descrip- 
tion. These are the logical structure of a diagram and its layout. The logical 
structure can be used for further extensions as, e.g., for code generation. 

4 Related Work 

Many different tools have been proposed supporting visual programming. The 
reader is referred to [Shu88,Gha90,BGL95] giving a broad overview. However, 
most existing tools are developed for specific application purposes. Moreover, 
the tools allow for visual programming and not for modeling languages like 
GenGEd. This means that the visual means are tightly integrated with the 
corresponding programming environment. In contrast to such environments, 
GenGEd is a generic framework based on a user-defined visual alphabet and a 
grammar. 

The purpose of GenGEd is the visual definition of visual languages. From the 
definition a language-specific Graphic Editor is generated. Some other 

® The alphabet is added automatically, so in fact we export a visual language specifi- 
cation. 
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approaches with the same purpose are to mention. These are e.g., 
Progres [SWZ99], DiaGen [MV95], and Vlcc [CODL95]. We have to mention 
that a comparison between GenGEd, PROGRESand DiaGen according to the 
underlying theory as well as the tools is given in [BTMS99]. A brief summary is 
given below. 

Progres is a graph-based framework allowing for programming with rules 
and for the generation of prototypes. The Progres environment offers assistance 
for creating, analyzing, compiling, and debugging graph transformation specifi- 
cations. Outside the Progres environment such a specification can be executed 
in a stand-alone prototype. In Progres, visual languages can be specified using 
the visual means of graphs. It is not possible to specify a visual language under 
consideration of the appearances of symbols as it can be done using GenGEd. 

DiaGen is a diagram editor generator. The input of the generator is a textual 
specification of a visual language. In general, visual statements are difficult to 
describe textually because of their graphical structure. This is due to the fact 
that multi-dimensional representations have to be coded into one-dimensional 
strings. Moreover, the DiaGen approach is concerned with a restricted kind of 
context-sensitive grammars. Hence, the class diagram language, e.g., cannot be 
specified using the DiaGen approach [BTMS99]. 

G.Costagliola et al. introduced the VLCC-environment [CODL95] supporting 
the visual definition of visual languages, too. A symbol editor can be used to 
define terminal and non-terminal symbols. The defined symbols are then avail- 
able within a production editor allowing the definition of context-free positional 
grammar rules. In contrast, we use grammars which are not restricted to be 
context-free. 

5 Summary 

In this contribution we informally introduced visual languages as they can be 
defined using the GenGEd environment. Similar to textual languages, a vi- 
sual language is defined by an alphabet and a grammar. Correspondingly, the 
GenGEd environment comprises an Alphabet Editor and a Grammar Editor. 
These editors as well as a generated Graphic Editor are described. An in-depth 
description of the design and the implementation of the environment can be 
found in [Sch99] and [Nie99], the underlying theory is depicted in [BarOO]. 

Despite the prototypical character of the environment, there are several case 
studies. These are restricted kinds of visual languages like statecharts, class di- 
agrams, sequence diagrams and Nassi-Shneiderman diagrams. Some more are 
yet to come. Thereby, we investigate how to integrate several visual languages 
similar to the UML in order to generate not only a Graphic Editor but a visual 
environment. Future work is concerned with a major overhaul of the Grammar 
Editor, simplifying the rule definition. Another idea is to change the generated 
Graphic Editor into a JavaBean, thus providing other tools (e.g., the Agg sys- 
tem) with a generic graphic display and making the underlying structure of a 
diagram accessible. We are also planning to allow for more freedom in diagram 
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editing, combining syntax-directed and freehand editing. The latter one is con- 
cerned with parsing. 



References 

BarOO. R. Bardohl. Visual Definition of Visual Languages based on Algebraic Graph 
Transformation. PhD thesis, Technische Universitat Berlin, Berlin, 2000. 
457, 458, 459, 469 

BGL95. Margaret M. Burnett, Adele Goldberg, and Ted G. Lewis, editors. Visual 
Object-Oriented Programming: Concepts and Environments. Manning Pub- 
lications Go., Greenwich, 1995. 468 

BNSOO. R. Bardohl, M. Niemann, and M. Schwarze. GenGEd - A Development En- 
vironment for Visual Languages. In Application of Graph Transformations 
with Industrial Relevance, LNGS. Springer, 2000. 457 
BTMS99. R. Bardohl, G. Taentzer, M. Minas, and A. Schiirr. Application of Graph 
Transformation to Visual Languages. In [Roz99f. 1999. 469 
Gha90. Shi-Kuo Chang, editor. Principles of Visual Programming Systems. Inter- 
national Editions. Prentice Hall, Englewood Cliffs, NJ, 1990. 468 
CODL95. G. Costagliola, S. Orefice, and A. De Lucia. Automatic Generation of Visual 
Programming Environments. IEEE Computer, 28(3):56-66, March 1995. 
469 

Gri96. P. Griebel. ParCon - Paralleles Losen von grafischen Constraints. PhD 
thesis, Paderborn University, February 1996. 463 
Har87. D. Harel. Statecharts: A visual formalism for complex systems. Science of 
Computer Programming, 8:231-274, 1987. 456 
MV95. M. Minas and G. Viehstaedt. Diagen: A generator for diagram editors pro- 
viding direct manipulation and execution of diagrams. In Proc. IEEE Sym- 
posium on Visual Languages, pages 203-210, 1995. 469 
Nie99. M. Niemann. Konzeption und Implementierung eines generischen Gram- 
matikeditors fiir visuelle Sprachen. Master’s thesis, Technische Universitat 
Berlin, 1999. 469 

NS73. I. Nassi and B. Shneiderman. Flowchart techniques for structured program- 
ming. SIGPLAN Notices, 8(8), 1973. 457 

Rat98. Rational Software Corporation. UML - Unified Modeling Language. Tech- 
nical report. Rational Software Corporation, 2800 San Tomas Expressway, 
Santa Clara, CA 95051-0951, 1998. http://www.rational.com/uml. 456, 
457 

Roz99. G. Rozenberg, editor. Handbook of Graph Grammars and Computing 
by Graph Transformations, Volume 2: Applications, Languages and Tools. 
World Scientific Publishing, Singapore, 1999. 470 
Sch99. M. Schwarze. Konzeption und Implementierung eines generischen Alpha- 
beteditors fiir visuelle Sprachen. Master’s thesis, Technische Universitat 
Berlin, 1999. 469 

Shu88. N.C. Shu, editor. Visual Programming. Van Nostrand Reinhold, New York, 
1988. 468 

SWZ99. A. Schiirr, A.J. Winter, and A. Ziindorf. The PROGRES Approach: Lan- 
guage and Tool Environment. In [Roz99j. 1999. 469 
TER99. G. Taentzer, C. Ermel, and M. Rudolf. The AGG Approach: Language and 
Tool Environment. In [Roz99]. 1999. 463 



VIP: A Visual Editor and Compiler for 

v-Promela* 



Moataz Kamel^ and Stefan Leue^ 

^ Department of Electrical and Computer Engineering, University of Waterloo 
Waterloo, Ontario N2L 3G1, Canada 
m2kamel@uwaterloo . ca 
http : //f ee .uwaterloo . ca/""m2kamel 
^ Institut fiir Informatik 
Albert-Ludwigs-Universitat Freiburg 
D-79110 Freiburg, Germany 
http : //www. inf ormatik.uni-freiburg. de/~leue 
leueSinformatik.uni-freiburg. de 



Abstract. We describe the Visual Interface to Promela (VIP) tool 
that we have recently implemented. VIP supports the visual editing and 
maintenance of v-Promela models. v-Promela is a visual, object-oriented 
extension to Promela, the input language to the Spin model checker. 
We introduce the v-Promela notation as supported by the VIP editor, 
discuss Promela code generation, and describe the process of property 
validation for the resulting models. Our discussion centers around two 
case studies, a call processing system and the CORBA GIOP protocol. 



1 Introduction 

As Davis argues in [2], a significant return of investment can be expected when 
investing resources into the early stages of the software design cycle: in particular, 
fixing design flaws at the requirements stage can be 200 times less expensive 
than fixing them at the maintenance stage. Even corrections at the architectural 
design stage can be 50 times more cost efficient than at the maintenance stage. 
The inherent complexity of concurrent real-time systems makes it necessary 
to employ mechanized, formally supported methods to analyze early life-cycle 
artifacts. In this context the main questions to be answered are whether the 
requirements are consistent and correct with the intended behavior of the system, 
and whether the system’s design correctly implements the requirements. 

It has been shown that state-based modeling and automatic model checking 
is an effective tool for answering these questions for concurrent reactive systems. 
Recent advances in model checking research have made verification based on 
state space exploration more feasible for realistic software problems [6,7]. How- 
ever, the introduction of formal methods in the software engineering process is 

* The work documented in this paper was largely performed while the second author 
was with the University of Waterloo. We are currently working on a public release 
version of the VIP tool, interested parties are requested to contact the authors. 
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often hampered by textual interfaces laden with mathematical notations. Visual 
formalisms, on the other hand, appear to enjoy broad acceptance in engineering 
practice. 

With the ever increasing complexity of concurrent, reactive systems that con- 
tinue to be designed, the requirements and high-level design models are becom- 
ing sizeable artifacts themselves. In order to facilitate the model development 
process, we propose the alignment of the modeling language of a state-of-the 
art formal analysis tool with the state of the art visual, object-oriented hierar- 
chical notations used in current software development. This has the benefit of 
fostering maintainability and evolvability of these models while increasing the 
chances that the models actually express the intentions of the designers and in- 
creasing the acceptance of formal analysis in the practical software engineering 
community. 

In this paper we present the prototype of a graphical user interface-based 
tool called the Visual Interface for Promela (VIP) that we have developed. VIP 
supports a visual language called v-Promela which is the graphical extension 
of Promela, the input language for the model checker Spin [8]. The tool pro- 
vides graphical editing capabilities for v-Promela models and generates standard 
Promela code from the graphical representation. In the process of describing 
VIP we also show how modeling of complex real-time systems for the purpose of 
formal analysis can be based on a state-of-the art visual object-oriented notation, 
and that efficient tool support can be provided. 

Related Work. VIP supports visual modeling using v-Promela. The v-Promela 
notation has first been described in [13] and [5]. The design of v-Promela was 
guided by a number of desiderata. First, we desired to use Promela/Spin val- 
idation technology without any changes to the existing model checker. Hence 
every feature of v-Promela had to be compilable into Promela. Next, we were in- 
terested in a visual notation that would capture both structural and behavioral 
modeling aspects. We were also interested in providing hierarchical modeling 
and object-oriented concepts. Finally, we have attempted to comply as far as 
possible with existing or emerging software design methodology standards for 
concurrent real-time systems. As a consequence, the v-Promela notation inher- 
ited largely from the UML-RT notation [16]. UML-RT, which evolved from the 
ROOM notation [15], is supported by an industrial-strength case tool (ROBE- 
RT ) and is expected to be a prominent player in the real-time systems domain 
in coming years. Some of the syntactic as well as some of the semantic aspects 
of UML-RT are not completely specified at this time. The authors of UML-RT 
suggest that these missing aspects can be derived from the definitions of the 
syntax and semantics of ROOM as given in [15]. The development of the VIP 
tool is described in more detail in [10] which also discusses some modifications 
of the original v-Promela proposal. 

Organization of the Paper. In Section 2 we describe the architecture of the 
VIP tool, and we illustrate the use of VIP in Section 3 through an example. In 
Section 4 we discuss the v-Promela compiler implemented in VIP. In Section 5 
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we show how to perform property validation in the context of our approach. 
Finally, in Section 6 we discuss further issues related to the implementation of 
VIP, and we conclude in Section 7. 



2 VIP Architecture 

To support the editing and maintenance of v-Promela models we have developed 
the VIP ( Visual Interface to Promela) tool. Figure 1 illustrates the functional 
architecture of VIP. We will describe the functionality of the VIP editor in the 
following section. The edited v-Promela models are compiled into Promela code 
by VIP, and the resulting Promela models can be validated by the Spin model 
checker. Spin error traces can then be re-interpreted in the context of the original 
v-Promela model. Currently, the re-interpretation has to be done manually. To 
store v-Promela models, we currently use JAVA class serialization. The use of 
this feature of the JAVA Development Toolkit saved considerable development 
time, however, to allow better future expandability we are currently working 
on implementing storage and retrieval functionality based on XML [17] schema 
definitions and an XML parser. 





Fig. 1. VIP tool architecture. Fig. 2. POTS Model editor. 



3 Modeling in VIP 

In this Section we describe the main features of the VIP graphical user interface. 
As a running example we use a simplified Plain Old Telephony System (POTS) 
call processing problem. The example consists of two User processes and two 
PhoneHandler processes contained in the environment of the POTS system. ^ 

^ In order to obtain models that can be translated into Promela all v-Promela models 
must be closed systems. Therefore, the environment behavior must be modeled as 
part of the system. 
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The User processes represent the behavior of the telephones which communicate 
with PhoneHandler processes which represent the call processing software inside 
the switch. The PhoneHandler processes are responsible for responding to events 
from the User processes as well as communicating with other PhoneHandlers in 
order to establish a voice connection. 

3.1 Structural Modeling 

Model Editor. The Model Editor is the starting point for creating v-Promela 
models. It allows the user to define the basic elements of a v-Promela model: 
capsule classes, protocol classes, and data classes. From the model editor the 
user can open editors for each one of the above mentioned basic elements. From 
the model editor, the user can also save the model or generate Promela code. 
Figure 2 illustrates the model editor for the POTS example. It specifies three 
capsule classes, three protocol classes, and a data class. 




Fig. 3. PhoneHandler 
capsule structure. 




Fig. 4. Structure of POTS system. 



Structure Editor The Structure Editor displays the internal structure of a chosen 
capsule class using the v-Promela graphical notation. The structure may consist 
of other capsule instances, buffers, synchronizers, ports, and connectors. Changes 
to the structure of the capsule class are automatically reflected in other views 
that contain an instance of the capsule class. 

Figure 4 represents the POTS system structure. Concurrent objects are called 
capsules in accordance with the UML-RT terminology. The POTS system con- 
sists of a high-level capsule class called POTS. It is decomposed into four contained 
capsules as indicated by the capsule references in Figure 4. None of the contained 
capsule classes is further refined. However, Figure 3 illustrates the internal struc- 
ture definition of the PhoneHandler capsule class. The black and white boxes 
at the border of the capsule denote in and outbound ports, respectively. Ports 
represent message passing interfaces for capsules. In contrast to v-Promela where 
ports are either uni- or bi-directional, all ports in VIP are uni-directional. Incor- 
porating bi-directional ports into VIP is part of future improvements which are 
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in-progress. The type of a port is a protocol class, see below for a discussion of 
their definition. Ports need to be connected to ports in other capsule instances 
to enable messages to be exchanged. Connectors^ as indicated by the labeled ar- 
rows in Figure 4, are used to establish connections between ports. The connector 
label shows the name of the connector and the message buffering capacity of the 
connector within brackets. Only ports of identical type can be connected, and a 
connector must join an out-port to an in-port. 

A capsule instance can have an associated replication factor that is greater 
or equal to 1. The replication factor specifies the number of capsule instances 
that will be generated at instantiation time. For simplicity of presentation all 
capsule instances in the POTS example have a replication factor of 1. 
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Fig. 5. Protocol class definition for POTS model. 



Protocol Classes. A Protocol class consists of a name and a list of message 
classes. Each message class has a name which identifies the message type and an 
associated message body type. Figure 5 illustrates the protocol class definition 
for the POTS example. The names of the protocol classes as well as the message 
class names are indicative of signals passed in a telephone switch. 






Fig. 6. Dataclass definition and usage in protocol class definitions. 



Data Classes. Figure 6 illustrates the definition of data classes in VIP based 
on the available Promela data types. If a data class is mapped onto a basic 
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Promela data type it merely serves as an alias for that type. However, a data 
class definition can also take advantage of the typedef construct in Promela. 
Figure 6 shows the definition of the data class subscriber_number as a record 
consisting of a short integer field area_code and an integer field phone_number. 
Compared to the data type capabilities of languages like UML-RT the v-Promela 
possibilities are rather limited. However, this restriction is necessary to allow 
exhaustive model-checking by Spin. The right side of Figure 6 shows how a 
data class definition is used to define a message body type. The dialdigit 
message of the UserToSwitch protocol is defined to have a message body type 
of subscriber_mimber. 




Fig. 7. Data 
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Fig. 8. Defining ports 
based on protocol class 
definitions. 



Data Objects. Data objects are instances of data classes that can be used in 
expressions. They are defined as attributes of capsule classes. Figure 7 illustrates 
the definition of a data object ph_number within the User capsule class as an 
instance of the subscriberjiumber data class. A data object may also be defined 
to be an array. 



Buffers and Synchronizers. UML-RT is very rigid in the way that it allows inter- 
process communication to happen. Communication between processes takes 
place exclusively through point-to-point message exchanges via ports. In con- 
trast, Promela allows arbitrary sets of processes to share channels or to syn- 
chronize via rendez-vous channels. In order to permit the more general modeling 
approach that Promela makes possible, v-Promela introduces the concepts of 
buffers and synchronizers. These concepts have been used in the CORBA GIOP 
example that is described in Section 5 and we have used them to model producer- 
consumer problems as well as semaphores. 



3.2 Behavior Modeling 

Behavior in v-Promela is modeled using hierarchical, communicating extended 
finite state machines. 
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Hierarchical State- Machines. The behavior editor in VIP allows for editing the 
state machine associated with a capsule class. In the POTS example, only the 
User and PhoneHandler capsules have state machines associated with them, as 
illustrated in Figures 9 and 10. The top-level state of any state machine has the 
name TOP. To illustrate the hierarchical nature of state machines in VIP, the 
refinement of the await_digit state of Figure 9 is shown in Figure 10. It should 
be noted that in the current implementation of VIP we consider two states with 
identical name labels to denote different states. We use various icons inside the 
state symbols to express attributes of the states. As an example, the circle in the 
lower left corner of the idle state in Figure 9 indicates that this state has been 
marked as a valid end state, and the icons in the await_digit state indicate 
that this state has a refinement and that entry code has been defined for it. 

Circled X and E symbols indicate exit and entry points for multi-level tran- 
sitions, respectively. Typical for the use of hierarchical state machines is the 
occurrence of chained and group transitions. For instance, if the PhoneHandler 
capsule is in any state contained within the await_digit state this state may 
be exited if the transition labeled onhook_ in its super state executes. v-Promela 
and VIP allow for explicit return or return to history semantics for hierarchical 
state machines. If an entry point is not connected to a contained state, the re- 
turn to history semantics will be chosen in the event of an incoming transition. 
Otherwise, the explicit return to a contained state is indicated by an arrow from 
the entry point to the contained target state. 




Fig. 9. PhoneHandler TOP state. 




Fig. 10. PhoneHandler 
TOP:await_digit state. 



Transition code. The labels on the state transitions in the previous state tran- 
sition diagrams have no executable semantics, they are merely used to identify 
the transition and to enhance readability of the state machine model. To attach 
enabling conditions and executable code to a state machine transition we open 
the transition’s property editor, as shown in Figures 11 and 12. There are two 
formats for specifying transition code. Figure 11 shows the UML style of defin- 
ing transition code. The code consists first of an event specification which in our 
implementation consists of the reception of a message from a port. In the editor 
we use pull-down menus that allow the user first to select a port from which the 
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message is to be received, and second to select a message type from the list of 
all messages that are allowable for the selected port. A guard can be specified 
as a side-effect free Promela expression. The chosen semantics is that only if 
the specified message is receivable and the guard is true will the transition be 
taken. The action can be an arbitrary Promela code fragment and will typically 
contain a send statement for a message. Care has to be taken that the code 
specified here is always executable and does not contain internal control flow 
loops. The current version of VIP does not parse the action code and hence it 
is the responsibility of the modeler to ensure that the code is meaningful. The 
second format, illustrated in Figure 12 shows the more liberal way of defining a 
transition. Unlike UML-RT, v-Promela transitions can be triggered by the exe- 
cutability of any Promela statement, in this case a boolean expression specified 
in the event clause. If the event clause evaluates to true then the action part 
will be executed. In this example a message of type busytone is sent to the port 
toUser. 

As illustrated in Figure 13, state entry and exit code will be executed when- 
ever a state is entered or exited, respectively. In our example this means that 
from whichever state we enter the await_digit state we will apply a dialtone 
signal to the user. This has bearing on the format in which transition code is 
specified. It could be argued that transition code could be specified by simply al- 
lowing an arbitrary Promela statement to be attached to a transition. However, 
exit code should be executed prior to executing the transition code, which would 
be impossible if we were not distinguishing a triggering event in the transition 
code. 





Fig. 12. Free-form transition defini- 
tion. 
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Fig. 11. Promela code in action portion 
of transition definition. 



Fig. 13. Entry code definition. 
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4 The VIP Compiler 

The basic principles of the Promela code generation are that capsules are mapped 
onto proctypes, protocols onto mtype declarations, and that ports with their 
connectors as well as buffers and synchronizers are mapped onto channel dec- 
larations. Message bodies are implemented as record structures (typedefs in 
Promela parlance) with one field for every message type that the protocol com- 
prises. Data objects are mapped onto Promela variables. For a more extensive 
discussion we refer to [14,5,10]. 

Ports. Ports form part of the interface to capsule classes. Accordingly, the 
VIP compiler generates ports as channel type parameters in the parameter 
list of the corresponding capsule class proctype. On instantiation of a proc- 
type, the VIP compiler generates the proper arguments to bind the correct con- 
nectors to the ports. For instance, in the POTS example the POTS proctype 
contains a channel declaration of the form chan toUser2105717128 = [1] of 
SwitchToUser The definition of the User proctype declares two ports (from- 
Switch and toSwitch): proctype UserCchan fromSwitch, toSwitch ) . In the 
body of the POTS proctype, the User proctype is instantiated and its ports 
are bound by the code run User( toUser2105717128, f romUser2016588168 
) . This scheme has the desirable property that ports can be referenced within 
the proctype without regard for which channel may be connected to it. 

State Machine Encoding. The v-Promela control states could be implemented 
in two ways: a) by using Promela variables, or b) by using Promela control state 
labels and goto statements. Measurements documented in [10] suggest that, 
while the state vector size for both variants is identical, the state space size 
for variant a) is about twice the size for variant b). We therefore implemented 
variant b) in VIP. The state name label is chosen such that it starts with the state 
name in the v-Promela model and the VIP compiler adds a numeric sequence to 
disambiguate states with identical v-Promela names. 

Transition Code. The code generated for transitions specified in the UML style 
starts with checking whether the specified message reception event is available 
by polling the relevant channel. The result is conjoined with the evaluation of 
the guard which yields the transition’s enabling condition. The firing of the 
transition will cause the sequential execution of the following code fragments: 
first the message reception is performed, next the exit code of the current state, 
then the action code associated with the transition, followed by entry code for 
the new state and finally the goto into the successor control state. Promela does 
not allow polling the state of synchronous rendez-vous channels. Therefore, in 
such cases the first part of the transition code consists only of the rendez-vous 
communication, and any specified guard will be ignored. Figure 14 illustrates 

^ The VIP compiler disambiguates element names by concatenating a unique identifier 
to the irame. 
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this mechanism for the offhook transition from the idle state of Figure 9. 
To enhance comprehensibility of the code, the compiler automatically inserts 
meaningful comments even if no entry or exit code has been specified. Note that 
the transition modeled here is a chained multi-level transition from the idle state 
into the wait sub-state contained in the await_digit state (c.f. Figure 10), and 
that the entry code defined for await_digit, i.e., toUser ! dialtone is executed 
during this transition. 



if 

/* 

if : : 

idlel723158139: 

:: f romUser? [of f hook] && true-> 
fromUser?UserToSwitch_msg; 

/* exit idle */ 

/* action offhook_ */ 

/* entry await_digit */ 
toUser ! dialtone ; 

/* entry wait */ 
goto wait2091208315 



correct_connectreq_audiblering */ 
received_ph_num.phone_number == l-> 
/* exit digit_received */ 

/* action 

correct_connectreq_audiblering */ 
toOtherHandler ! connectreq; 
toUser ! audiblering; 

/* exit await_digit */ 

/* action connectreq */ 

/* entry originator */ 

/* action untitled */ 

/* entry party_ringing */ 
goto party_ringingl956295048 



Fig. 14. Transition code for pig. 15 . Transition code for free-form 

UML-style. chained transition 



Figure 15 illustrates the generated code for the VIP free form format for 
transition code specification. In this case the enabling condition is specified by 
an equality test on the value of a variable. The example also illustrates a chained 
transition, i.e., one that crosses nesting levels in the hierarchical state machine. 
All relevant entry and exit code specified along the transition chain is inlined 
into the transition code which, in certain cases, allows it to be processed as one 
atomic action^. 

Priority Schemes for Group Transitions. The implementation of group transi- 
tions depends on the priority model the user wishes to adopt. Three possible 
transition priority schemes are possible. In the first scheme, higher-level (group) 
transitions could take priority over lower-level transitions. Alternatively, lower- 
level transitions could take priority over higher-level transitions. Finally, both 
high and low-level transitions can be given equal priority. In VIP, all three prior- 
ity schemes have implemented with the user having control over which scheme is 
used. Equal priority is the default in VIP. It is implemented simply by combining 
both high-level and low-level transition code as separate conditions in the same 

® Promela allows non-blocking statements to be grouped into an atomic clause which 
can improve model checking efficiency. 
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ringing62399654 : 

{if 

:: fromUser? [of fhook] ... 
fi } unless { 
if 

: : fromUser? [onhook] . . . 

: : f romOtherHandler? [disconnect] 
fi} 



ringing62399654 : 

{if 

:: fromUser? [onhook] ... 

:: f romOtherHandler? [disconnect] 
fi } unless { 
if 

:: fromUser? [of fhook] ... 
fi} 



Fig. 16. Priority on grouptransition Fig. 17. Priority on local transition 

ringing2063158907 : 
if 

:: fromUser? [of fhook] ... 

: : fromUser? [onhook] . . . 

: : f romOtherHandler? [disconnect] . . . 



if ... f i statement as illustrated in Figure 18. Promela semantics dictate that 
multiple enabled conditions in an if statement are chosen non-deterministically 
resulting in equal priority among alternatives. The other two priority schemes are 
implemented using the Promela {A}unless{B} construct which pre-empts state- 
ments in A if the statement in B becomes executable. The first priority scheme 
is implemented by placing high-level transition code in B and low-level code in 
A. The second scheme implements the reverse. Figures 16 and 17 illustrate both 
of these schemes. Note that only the non-pre-emptive scheme complies with the 
run-to- completion semantics of UML-RT as described in [15]. 

5 Property Validation 

Property validation of VIP-synthesized models currently relies on using the 
Spin model checker to analyze the generated Promela models. The interpreta- 
tion of the validation results that Spin produces in the context of the v-Promela 
model currently relies on manual interpretation. We discuss two validation case 
studies using VIP-generated Promela code. 

Validation of POTS. The previously presented POTS model was designed with 
the intention of revealing most of the significant features of v-Promela as sup- 
ported by VIP. As a consequence, little attention was paid to developing a flaw- 
less model of POTS. The described POTS model is not free of deadlock. We 
have labeled the idle state in the PhoneHandler process and the on Jiook state 
in the User process as end-states and an end-state check in Spin easily shows 
a trace that terminates with one process an invalid end-state. This is mainly 



fi 



Fig. 18. Transition code with equal priority 
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due to the fact that we have not synchronized the User and PhoneHandler in- 
teractions. Thus, the User can repeatedly generate offhook and onhook event 
sequences that will eventually fill up the channel to the PhoneHandler. Also, 
call processing software is rarely “live”, i.e., it only satisfies trivial liveness prop- 
erties. A progress test in Spin easily shows offhook and onhook cycles that do 
not imply system progress. 

We therefore decided to answer the question of whether our POTS model 
was at all capable of doing it’s very raison d’etre, namely to connect two phones. 
In order to show that such a scenario exists, we formulate the converse property 
(namely, that the scenario does not exist) and hope that Spin would refute the 
claim by showing us a trail to the contrary. The property we seek to prove is: 
“there exists a scenario in which both PhoneHandler processes are in the respec- 
tive conversation states.” The converse of the property is: “it is never the case 
that, at the same time, one PhoneHandler process reaches the conversation state 
for an originator and the other reaches the conversation state for a terminator.” 
This property is represented by the LTL formula: ! <> (p && q) where p and q 
are defined in Spin by the state propositions: 

#define p (PhoneHandler [2] @conversation_origl985130888) 

#define q (PhoneHandler [3] @conversation_term2034323067) 

These expressions are referred to as remote references in Promela parlance. The 
expression PhoneHcUidler [2] @conversation_origl985130888 is a boolean ex- 
pression that evaluates to true if the process named PhoneHandler with process 
id equal to 2 is at the control state labeled conversation_origl985130888. 

Shortly after running the model checker on the above claim, an error trace 
was found. As expected, the error trace that Spin found showed a scenario in 
which both Phone Handler processes were in the respective conversation states. 
The validation required matching appr. 448,000 states, 680,000 transitions and 
45.5 MByte of memory. 

Validation of CORBA GIOP. In a previous work we modeled and formally 
validated the Common Object Request Broker Architecture (CORBA) Gen- 
eral Inter-ORB Protocol (GIOP) [4] using Promela/Spin validation technol- 
ogy [11]. In that work, a hand-built model of GIOP was developed and validated 
in Promela. Subsequently, a v-Promela model of GIOP was created using the 
VIP tool. The v-Promela model of GIOP has the equivalent functionality of 
the scaled-down, hand-built model that was validated in [11]. It comprises two 
User, two Server, one GlOPClient and two GIOPAgent processes. The model 
structure is shown in Figure 19. Behavior of the various capsules is defined using 
non-hierarchical v-Promela state machines. 

Certain limitations of the VIP tool caused difficulty in expressing the struc- 
ture of the model in a natural way. For example, replication of capsule instances 
was not implemented in the tool at the time the experiments were run and 
therefore, multiple instances of capsules had to be explicitly shown in the model. 
Similarly, replicated ports and channels were also not available in the tool and 
thus, buffers were used to emulate the desired communication structure. 
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Fig. 19. Structure of the v-Promela GIOP model. 

In the v-Promela model of GIOP, messages destined to the GlOPClient from 
either of the User processes are merged into a single buffer called toClientU. 
Similarly, messages destined for the GlOPClient from either of the GIOPAgent 
processes are merged into a buffer called toClientL. In the opposite direction, 
the GlOPClient may send messages to the User or GIOPAgent by placing them in 
the toUser and toAgentL buffers respectively. The messages are tagged with the 
Promela process id (pid) of the receiving process which only receives messages 
that contain its pid as a tag. 



Table 1. Verification of safety and progress properties of hand-built versus au- 
tomatically generated code. 



Model 


Property 


State vector 


Depth 


States 


Transitions 


Memory usage 


hand-built 


safety 


244 byte 


119 


77,261 


92,566 


17.697 Mb 


VIP 


safety 


256 byte 


171 


8,704 


13,236 


4.590 Mb 


hand-built 


progress 


248 byte 


229 


237,157 


534,157 


49.032 Mb 


VIP 


progress 


260 byte 


223 


13,641 


36,376 


5.819 Mb 



A basic safety properties verification run was carried out on the two models. 
This checked for invalid end-states and assertion violations. Equivalent assertions 
were placed in both models to check for invalid conditions such as reception of 
a Reply when no Request was outstanding. Also, end-state labels were placed 
in both models to identify valid end-states in each process. To validate progress 
properties a progress label was inserted into the models where the User process 
reaches the UReplyRecvd state. Both models ran with no violations on the safety 
as well as the progress properties. The results are shown in Table 1. As can be 
seen, the VIP generated code, although it required a larger state vector, resulted 
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in a significantly smaller state space. This can be attributed to two factors. 
First, the state encoding of the VIP generated model uses goto statements while 
the hand-built model uses an event loop construct in which control states were 
represented through variables. It was shown in [10] that this difference alone 
can account for a doubling in state space size. Second, the hand-built model 
uses global variables for all channels whereas, the VIP generated code declares 
channels as being local variables of the Env process. In [10] it was also shown 
that the use of global variables can reduce the effectiveness of the partial order 
reduction algorithm and thus also contributes to a larger state space. 

To model the occurrence of events in the state-based model checker Spin we 
used the previously described concept of remote referencing. For example, the 
remote reference: 

#define p (GIOPAgent [5] OSRequestSent) 

refers to a label SRequestSent introduced into the action part of the transition 
code within a state-machine in the GIOPAgent capsule. It corresponds to the 
state after the SRequest message has been sent. 

For the hand-built GIOP model, ten high-level requirements (HLR) were 
formulated and verified in [11]. Of the ten requirements, two were explicitly 
checked on the VIP generated code for the GIOP model. Some other require- 
ments were checked implicitly through the use of assertions. All requirements 
that were checked were exhaustively verified successfully on the VIP generated 
model. This serves to confirm that the required behaviors present in the hand- 
built model are also present in the VIP model and that the VIP-generated code 
does not cause a prohibitive state space size penalty. 



6 VIP Implementation 



VIP was implemented in the Java programming language using Sun Microsys- 
tem’s freely available Java Development Toolkit version 1.2. This allowed us 
to achieve a highly portable tool while leveraging Java’s extensive GUI sup- 
port. In developing VIP we adhered to a strict model- view separation which 
has enhanced flexibility and reuse in the design. To achieve maintainability, a 
quintessential requirement in the academic environment in which VIP was built, 
all class structures have been documented in UML. The graphical editors used 
in VIP are based on a separately developed component called Nexus. Other 
components such as windows and dialog boxes are based on standard Java class 
libraries. 

As discussed in [10], VIP contains a set of approximately 30 well-formedness 
rules, the majority of which are checked whenever a model component is changed 
as a result of changes in the view. An example rule is that "... a connector can 
only connect Ports that are protocol compatible...” 
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7 Conclusions 

We introduced the VIP tool which permits the creation and editing of v-Promela 
models as well as the compilation of these models into Promela code. We showed 
that the resulting models are analyzable using standard Spin model checking 
technology. 

The current version of VIP supports many features of v-Promela. A major 
thrust in research and development effort will be needed to develop VIP into 
a comprehensive CASE tool for requirements and high-level design. First, the 
aspect of property specification is currently not supported very strongly. We 
hope that an incorporation of ideas stemming from the temporal logic specifi- 
cation pattern approach [3] and from graphical interval logics [12] will facilitate 
the specification of requirements. We will also design ways of relieving the user 
from having to build hooks inside the synthesized Promela code, for example 
by introducing labels, by allowing property formulae to refer to states and vari- 
ables in the v-Promela model. Next, we plan to feed the Spin validation results 
back into the VIP environment including an animation of simulation and error 
traces inside VIP^. We also intend to explore linking the v-Promela models to 
other model checking tools by suitable intermediate representations as for in- 
stance the IF representation [I]. The question of the different priority schemes 
for implementing transition code has highlighted the need for parametric seman- 
tics in order to remain compatible with other modeling tools and methods. We 
plan, in particular, to develop a set of semantic options that will allow analyzing 
models which have semantics identical to UML-RT. Finally, some concepts from 
v-Promela such as structural and behavioral inheritance as well as data object 
scoping have not yet been implemented and we plan to add these as well. 

We hope that by reconciling an industrial standard visual modeling language 
like UML-RT with the input language of a model checker, and by providing 
suitable tool support we can contribute to increasing the acceptance of formal 
methods in the practical software engineering community. 
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Abstract. In this paper we describe and compare two methodologies for 
verifying the correctness of a speculative out-of-order execution system 
with interrupts. Both methods are deductive (we use PVS) and are based 
on refinement. The first proof is by direct refinement to a sequential 
system; the second proof combines refinement with induction over the 
number of retirement buffer slots. 



1 Introduction 

Modern out-of-order super-scalar microprocessors use dynamic scheduling to in- 
crease the number of instructions executed per cycle. These processors maintain 
a fixed-size window into the instruction stream, analyzing the instructions in the 
window to determine which can be executed out of order to improve performance. 
Branch prediction and register renaming are employed in order to keep the win- 
dow full, while result-buffering techniques maintain the in-order-execution model 
required by the architecture. 

In this paper we discuss two refinement-hased proofs of the correctness of 
such processors. Our model is based on the Tomasulo algorithm in [13,4] and [6], 
with modifications for in-order-retirement and speculative instruction prediction 
adapted from [-5]. This paper is a continuation of the work on out-of-order exe- 
cution presented in [4,2] and [10]. We extend the methodology of these papers to 
deal with exceptions and speculative instruction execution, while also presenting 
a new, inductive, methodology. Both proofs have been verified using the PVS [9] 
theorem prover^. 

In the first proof, which we refer to as the direct proof, we use a top-down 
methodology to generate and prove the system invariants needed to prove that 
our speculative system refines a sequential system. Starting with the final invari- 
ant to be proved, this methodology allows the user to systematically generate 
and prove all other necessary invariants. 

In the second proof we combine refinement and induction. Under the premise 
that the more similar two systems are the easier it should be to prove refine- 
ment between them, we use induction to generate two refinement proofs between 
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dation and a gift from Intel. 
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similar systems. Noting that the number of instructions which are in progress 
in an out-of-order system is limited to the number of retirement buffer slots, we 
first show that a speculative system which has only one buffer slot (and thus 
functions sequentially) refines a sequential system, and then, that a system with 
B + 1 buffer slots refines one with B slots. The base case thus deals only with the 
differences in data structures, while in the induction step we focus on the effect 
of the greater measure of ‘out-of-order’ness allowed by one additional buffer slot. 

Due to the enormous differences between sequential and speculative systems 
it is not immediately obvious how the first may refine the second. However, it is 
easy to anticipate that a system may refine another with one more retirement 
buffer. Thus, our intuition was that the inductive proof would prove to be simpler 
than the direct one. However, this proved not to be the case. While the run-time 
of the direct-proof is somewhat longer than that of the inductive proof, the 
inductive proof required far more intricate human interaction, taking far more 
person-time. We believe that not only was the inductive proof more complex in 
this case, but that using induction will frequently complicate refinement proofs. 
This evaluation is discussed in the final section of the paper. 

While there is a lot of work in the field of out-of-order executions, not much 
has been published on speculative execution. It is unclear whether, or how, tech- 
niques used for out-of-order execution can be applied to speculative instruction 
execution. Candidate techniques which have been used to verify out-or-order ex- 
ecution include the completion function approach [7], incremental flushing [12], 
compositional model checking [8] , and techniques combining model checking with 
uninterpreted functions [3]. 

A speculative system is verified in [11]. This system is more complex than 
ours, including memory operations, but the proof is specific to one configuration. 
An intermediate model comprising a table of history variables is used to verify 
the system in ACL2. Our proofs have the advantage of being independent of the 
system configuration and of not requiring an intermediate abstraction. 



2 Refinement between Systems 



Refinement is the comparison of an abstraet system at Pa) ^ 

concrete system p^) where V is the set of system variables, 0 

defines the initial conditions of the systems, and p, the transition relation, de- 
fines how the system progresses from one state to another. The abstract system 
serves as a specification capturing all the acceptable correct computations of the 
concrete system. Correctness of the concrete system is established by proving 
that every computation of corresponds to some computation of Sa ■ 

The correspondence between the two systems is with respect to observation 
functions O a and . Intuitively, these are the features of the two systems which 
are considered significant for the comparison. For example, in instruction execu- 
tion systems one would expect the register file to be included in the observation 
functions while internal data structures might not be. 
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Given a concrete system = {V ^ , 0^ , ) with observation function , 

and an abstract system = {V^,0^, p^) with observation function O^, such 
that Vp n = 0, we define an superposition system 

Ss = {V^UV,,0^A0,,p^Ap\) 

where P*a{V^ ,V^,V^,V'^) may refer to all variables in U in their primed 
and unprimed versions. 

The intention of the superposition system Ss is that it emulates the joint 
behavior of and in a way that allows any previously admissible step of 
and matches it with an S^-step. Thus, p^ A p\ should not exclude any possible 
S'(,-step, but may select among the possible S^-steps one that matches the S^- 
step. Intuitively, p\ is a modification of p^ taking as parameters and in 
order to choose a -successor matching the S'^-step. We further require that 
the projection of an S's-computation onto is a legal computation of 

In any superposition system Ss satisfying the above requirements the prob- 
lem of showing that S^ O is reduced to the problem of showing that 
is an invariant of Ss- However, to do so it may be useful, or necessary, to prove 
a stronger invariant, a{V^, V^) of the superposition system. 

We formalize this as refinement rule ref: 

Rl. a A Pc — > 3IG : p\ 

R2.p^ ^ P. 

R3. Ss 1= □ q; 

R4. a — > Oc=0^ 

Sc^S, 

That is, S^ refines S^ if using p\ a legal (R2) computation of Ss can be gener- 
ated (Rl) such that 0^ always equals (R3, R4). 

3 The Reference Model: System SEQ 

In this section we present system SEQ which is to serve as a reference model. 
System SEQ executes in a strictly sequential manner an input program which 
may contain branches and instructions generating interrupts. It accepts one pa- 
rameter, i?, the number of registers. 

An uninterpreted function, prog, from PC -RANGE to instructions defines 
the program to be executed. Each instruction has an operation, a target and 
two source operands. In addition, a branch target field stores the target address 
of branches. A program counter, pc, points to the next instruction in prog. A 
register file reg records the current values of each register. 

At each step, system SEQ either delays, in which case no change is made 
in the system, or executes the instruction pointed to by pc. If the instruction 
execution generates an interrupt, the program counter is updated to point to 
the relevant interrupt handler address. In the case of branches, the branch is 
evaluated and the program counter updated to the branch target if the branch 
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is taken. The do-op and doJ)ranch functions are used to compute the value of 
the instruction {do.branch returns “1” if a branch is to be taken, “0” otherwise). 
This value is stored in the target register (if any), and the program counter is 
updated to point to the next instruction. 



4 The Out-Of-Order Design: System DES 

In this section we briefly describe our algorithm for speculative out-of-order 
data-driven instruction execution with in-order-retirement. Our definitions are 
based on the descriptions in [6,4] and [5]. 

Instructions flow from the instruction queue to the retirement buffer, where 
they assume their places in the queue for retirement, and the dispatch buffer, 
where they await availability of their source operands and a free execution unit. 
Branch instructions are predicted at dispatch time and the program counter 
updated accordingly. Once both operands are available execution of the instruc- 
tion can be initiated by the appropriate functional unit. As in system SEQ, the 
instruction value is calculated by the do-op and do-branch functions. During 
execution an internal interrupt can be generated, in which case a flag is set in 
the retirement buffer slot. Results are written back to the retirement and dis- 
patch buffers. Once an instruction reaches the head of the retirement queue it is 
checked for an internal interrupt or branch misprediction before being retired. If 
an interrupt was generated the program-counter is updated to the appropriate 
interrupt handler address and the dispatch and retirement buffers are flushed. If 
no interrupt was generated the system checks branches for mispredictions. Mis- 
predictions result in the program counter being updated to the instruction which 
should follow the branch, while dispatch and retirement buffers are flushed. In- 
structions which generated neither interrupts nor incorrect predictions can be 
retired, updating the register file with the instruction result. 

The data structures of system DES are illustrated in Fig. 1. The shaded 
fields are auxiliary variables which have been added to our model in order to 
simplify the proofs. Auxiliary variables are only updated and copied from one 
record to another and thus do not affect the flow of control. The two proofs use 
different auxiliary variables, the unified set of which are shown in the diagrams 
for completeness. The numinst variable counts the number of instructions retired 
so far and is used in synchronizing the two sequential and speculative systems. 

The functionality of system DES can be divided into three subsystems: 

• DISPATCH: This module dispatches instructions in program order. 

• EXECUTE: This module executes and writes back instructions. 

• RETIRE: This module retires the slot at the head of the retirement buffer. 

While only one instruction is dispatched or retired per cycle, module execute is 
parameterized by the number of functional units: when this module is invoked, 
each functional unit in the system may execute and write-back a result. Multiple 
instructions may be executed and written back in each cycle. 
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Fig. 1. Data structures for des 



In practice these three subsystems operate concurrently. That is, in the same 
cycle all three can be invoked simultaneously. Any concurrent execution of the 
three subsystems is equivalent to a three-step sequential execution of the sub- 
systems in which each subsystem is executed once. We therefore consider each 
of the three systems separately, ignoring the possible interaction between them. 

A note on the retirement buffer The retirement buffer, RB, is the central 
data structure in the system. It stores instructions in dispatch order until their 
retirement, ensuring that retirement is in-order. The buffer contains a circular 
array rbe of retirement buffer entries. This array is treated as a queue, with the 
oldest entry being “popped” off during retirement, while dispatched instructions 
are “pushed” onto the end of the queue. The pointers head and tail point to the 
head of the queue and the next free slot, respectively. 

The use of predicted values The inductive proof utilizes the auxiliary pre- 
dicted value fields. Every value field v in the system is paired with an auxiliary 
predicted value pv field, while the interrupt field int in the retirement buffer 
slots is matched with an interrupt predict field, intpv. 

When an instruction is dispatched its predicted values are calculated. The 
predicted value of arithmetic operations are calculated by applying the instruc- 
tion operation to the predicted values of its operands. 

The generation of interrupts and taking of branches are decided by the un- 
interpreted functions interrupt and doJjranch, respectively, whose parameters 
are available at dispatch time. The same functions and parameters are used to 
predict whether an interrupt will be taken (intpv) and the predicted value (pv) 
of a branch instruction. Both predictions are trivially correct. 
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Note: The predicted instruction value, stored in the pv field of the retirement 
buffer should not be confused with the system’s branch prediction stored in the 
brpv field. The latter is calculated using a different function and is not guaranteed 
to be correct. 

5 Our Direct Proof that DES Refines SEQ 

In this section we discuss our direct proof that system DES refines system SEQ. 
The bulk of this proof is the proving of invariants used to show that the ob- 
servable functions of the two systems match. We first discuss our ‘top-down’ 
methodology and then explain how it was applied to this problem. 



5.1 A Two Stage Top-Down Approach to Invariant Generation 

Deductive proofs typically include a number of inter-dependent invariants. The 
human prover, faced with the necessity of proving a fairly complex property 
may be uncertain how to begin. We define a simple two stage procedure which 
we believe provides a framework for proving such invariants in a systematic 
manner. We note that while only the second step of this procedure is ‘top-down’ 
the dominance of this step leads us to call the whole procedure ‘top-down’. 

1. Formulate, and prove, a set of simple invariants of the data structures and 
the model. These invariants can be chosen with little or no consideration of 
the invariant to be ultimately proved. Good candidate properties for this step 
are simple properties of data-structures or relationships between two data 
structures. Properties chosen in this step are typically sufficiently simple that 
they are not dependent on any other properties. 

2. Attempt to prove the final correctness invariant using the invariants proved 
in step one. Should the proof reach a step from which one cannot progress, 
analyze the situation, define one or more properties which would allow the 
proof to progress and attempt to prove these properties. 

The purpose of the first step is threefold. Firstly, it is likely to expose simple 
errors in the model, should they exist. It is frequently the case that in writing up 
the model in the PVS description language an error was made, often a very simple 
one such as using an incorrect index for an array. Such errors may cause the proof 
of even simple invariants to fail, and the simpler the proof which fails the easier 
it is to locate the problem in the model. Secondly, the construction of incorrect 
properties reflects user misunderstanding. Discovering why such properties are 
incorrect helps the user comprehend the model more completely. Thirdly, even if 
these properties were not formulated with the final invariant in mind, they will 
almost certainly be useful in its proof. 

In the second step constant progress is made towards the conclusion of the 
proof. When the proof fails, and it is expected to, it is generally due to the 
necessity of proving another invariant first. The second step thus incrementally 
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reveals the “hidden” properties on which the desired invariant is dependent, 
generating a string of properties to be proved invariant. The recursive proving 
of invariants should conclude after a few iterations, allowing the model to be 
proved correct. 

The balance between the two steps is variable. The greater the number of 
invariants proved in the first step the less frequently the proofs of the second 
step will fail due to missing properties or simple errors in the model. However, 
there is no need to worry about too few, or “missing” invariants in the first step. 
All invariants needed in the proof will be revealed in the second step and can be 
proved at this point. While invariants proved in the first step will typically be 
useful, they are not strictly necessary. 

The framework described is very flexible, but, we believe, firm enough to 
provide structure and direction to the proof. 



5.2 System des refines system SEQ 

Auxiliary variables used: The auxiliary variables used in this proof are the 

reg field in the operand structures, and the oc and arg fields of the retirement 
buffers. 

Both SEQ and des have program counters called pc and counters numinst count- 
ing the number of instructions which have been completed. We will term the 
variables in SEQ pc^^ and numinsta and those in des pc^ and numinstc- 

For we restrict by modifying the delay variable such that SEQ delays 
when the two systems have completed the same number of instructions: 

delay := {numinsta = numinstc) 

The system invariant, a, is simply the conjunction of the single system invariants 
and the equality , with the observation functions defined as: 

: {RF, numinstc, if RB.head = RB.tail A ^RB .wrap 
then pCc else RB ,rbe[RB ,head].pc ) 

: {reg, numinst a, pc a) 

Thus, the register files of the two systems always agree. When the retirement 
buffer is empty the program counters also agree. Otherwise, the program counter 
of the next instruction to be retired matches the program counter of SEQ. 

Proving premises Rl, R2 and R4 of the refinement rule is easy, the difficult 
part is in proving that = O ^ is an invariant of the system. To do this we 
must prove that both machines compute the same value for each instruction, 
and modify the program counter identically. Since both the value and the pro- 
gram counter are influenced by taking an interrupt, we must also show that an 
instruction generates an interrupt in system des if and only if it does so in SEQ. 
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5.3 Invariants Used in Proving the Refinement 

In the first stage we prove simple properties of the system, for example, lemmas 
relating to the structure of the retirement buffer (e.g. if tail and head point to 
the same slot then the retirement buffer is full if wrap is true, empty otherwise) . 

We consider now the second stage of the proof. We start by trying to prove 
that the value in the head retirement buffer slot is the value calculated by SEQ for 
the given instruction. This property is quickly formalized and divided into four 
properties. The first states that the value in the head slot is the value that would 
be obtained by applying the do-op or do-branch functions to the values in the 
operand registers: 

4>i \ RB .rhe[RB ,head].oc /\ ^RB .rhe[RB .head].husy — > 

RB .rhe[RB ,hea(l].v = 

if type-op{RB.rbe[RB.head].op) = branch 
then doJ>ranch{RB . rbe [RB . head] .pc , 

issJ}efore{numinst, RB, RB.head)) 
else do-op{RB .rbe[RB ,head].op, 

RF[RB .rhe[RB .head].arg[V\.reg], 

RF[RB . rbe [RB .head] . arg [2] . reg ] ) 

However, this invariant is insufficient: the values stored in fields of rbe must 
be matched to counterparts in SEQ to allow us to prove that the computed 
values are correct. This relationship is asserted by showing that the operation, 
register, target and branch target fields in the retirement buffer match those in 
the program used by both systems. We must also prove that the two systems 
use the same criteria to generate interrupts, and will thus generate interrupts 
at the same time. Lastly, it is necessary that the program counters in the two 
systems match, if not they will execute different instructions. Whereas in a purely 
sequential program the updating of the program counter is trivial, once branches 
are considered the relation between the instruction indices of two instructions 
that complete one after the next may vary and the correspondence between the 
program counters is more complicated. 

Of these properties, the relationship between the retirement buffer and the 
program, and the matching interrupt generation are simple to prove while prop- 
erty (j>i is the most difficult. We concentrate on the proof of this property. 

Property (j>i is, intuitively, stating two phenomena - firstly, that the result 
of the instruction is that obtained from the operands used, and secondly, that 
the values of these operands can now be found in the register file. This second 
property, operand correctness, depends primarily on operands with “retired” 
status having values matching those in the register file: 

02 : RB.rbe[rb].oc A RB .rbe[rb].arg[j].st = retire — > 

RB .rbe[rb].arg[j].v = RF[RB .rbe[rb].arg[j].reg] A 
Vrfc' RB.rbe[rb'].oc A RB .rbe[rb'].tgt = RB .rbe[rb].arg[j].reg — > 
rb = rb' V preceed{rb,rb' , RB) 
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where preceed{rb^rb' ^ RB) is true iff both retirement buffer slots are occupied 
and slot rb precedes slot rfc' in the queue of slots waiting for retirement. 

The need to prove that there is no preceding retirement buffer slot targeting 
the operand registers is crucial: should such a slot exist it would, on retiring, 
over-write the values in the register file, invalidating any correspondence between 
the retirement buffer slot operand fields and the register file. 

Property (j)2, in turn, depends on the value in operand fields matching the 
closest preceding slot targeting the operand register, when such a slot exists. 
Property (j>3 asserts that while the operand status is write_b (the operand value 
has been written back but the instruction has not yet been retired) such a slot 
does exist, and its value matches that in the operand fields. In order to prove that 
there is no slot targeting the registers matching retired operands, as required in 
(j>2, it is necessary now to prove a parallel property: there is no slot targeting 
the operand register between the instruction slot and the slot pointed to by the 
operand fields. 

In order to prove the invariance of (^3 it is necessary to define an invariant, 

defining similar properties for busy operands. 

Proving the invariance of (j)2, 03, and 04 is the most difficult part of the 
direct proof. Intuitively, these properties assert the correctness of the relation- 
ship between instructions and their operands, that instructions always use the 
value calculated for the operand by the last preceding instruction writing to the 
operand register. These dependency relations are one of the difficulties of out-of- 
order executions, and it is unsurprising that proving that they hold is the crux 
of our correctness proof. 

We proved a total of 23 invariants in our proof, many of which were simple 
technical results, such as proving that if the head and tail pointers of the 
retirement buffer are equal then the buffer is either full or empty. We omit 
further details of these invariants. 



6 An Inductive Proof of Refinement 



There is an enormous difference between an out-of-order system in which many 
instructions progress simultaneously and a simple sequential system. Whereas in 
the direct approach we prove a correspondence between these diverse systems, 
the inductive approach is based on the premise that it will be easier to prove 
a number of smaller refinements between systems which are more similar. This 
approach requires more user effort in defining the multiple refinement relations, 
an investment which simplifies the invariants which need to be proved. 

We have performed induction on the number of slots in the retirement buffer. 
In the base case, where there is only one slot, the out-of-order machine will 
operate sequentially as only one instruction can be in progress. The inductive 
step involves proving that machine des(b-|-1) with B +1 slots refines one with B 
slots (denoted des(b)). The difference between these two machines is intuitively 
far less than that between an out-of-order system and a sequential one. 
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The invariants needed to prove the refinement relations were proved using the 
top-down approach detailed previously. In fact, many of the properties needed 
were proved as part of the direct proof. 

Auxiliary variables used: The predicted value fields in the dispatch and re- 
tirement buffers are used, as are the oc and slot fields of the retirement buffer. 

6.1 Base Case: des(1) Refines SEQ(r) 

We consider DES(l), an implementation of des with only one retirement buffer 
slot. As was the case of the direct proof, we synchronize the two systems at 
retirement time by setting the delay variable exactly when the numinst variables 
of the two systems agree. Details of this straightforward proof are omitted. 



6.2 The Inductive Step: des(b-|-1) Refines des(b) 

We show that a system with B + 1 retirement buffer slots refines one with B 
slots. We have chosen to synchronize at instruction dispatch time. 

There are two difficulties here: Firstly, des(b-|-1) can store B + 1 issued 
but incomplete instructions whereas des(b) cannot; secondly, even when the 
two systems contain the same number of occupied retirement buffer slots, their 
positions will be different since as soon as the head pointer wraps the head point- 
ers of the two systems will differ. This technical problem complicates the proof 
which we therefore divided into two stages. We first prove that des(b-|-1) re- 
fines deS/(b-|-1), a system with B + \ slots in which there is always at least one 
free slot. We then show that deS/(b-|-1) refines des(b). That is, the first proof 
proves that a system functioning with one fewer slot refines des(b), without 
considering mismatched slot positions, a problem delayed to the second proof. 



DES(B-|-l)refines deS/(b-|-1): We run the two systems in parallel, synchroniz- 
ing at instruction issue. As long as there is at least one free slot in des(b-|-1), 
all the data structures in the two systems are identical. We consider the case of 
an instruction being issued into the last free retirement buffer slot of des(b-|-1). 

We cannot issue the instruction in system deS/(b-|-1) as this system will not 
allow all i? -I- 1 slots to be occupied simultaneously. We free the slot at the head 
of the retirement buffer (that pointed to by head) and then issue the instruction. 

We consider first the case of the head slot containing an executed instruction 
(the busy flag is false) which is not a mispredicted branch, nor generates an 
interrupt. This instruction is retired, after which system deS/(b-|-1) issues the 
new instruction. The register files of the two systems are equal except that the 
value of the target register of the head slot is updated in des(b-|-1) with the 
value found in the head slot in deS/(b-|-1). 

However, it may be the case that no value is yet available in the head slot as 
the instruction has not yet been executed. In this case the instruction is stored 
in the dispatch buffer pointed to by the auxiliary slot field of the retirement 
buffer entry. Any operands of the instructions depended on values of previous 
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instructions, all of which have been retired, and so the instruction will have 
available operands and can be executed. After execution, the instruction can be 
retired and the new instruction issued. 

The fact that des(b+1) does not have any value for the instruction makes 
matching the two systems more difficult. The new value in the register file (as- 
suming that the retired instruction had a target register) of deS/(b-|-1) is not 
found anywhere in the des(b-|-1) system. This problem has been overcome by 
using predicted values. The value which has been calculated and retired should be 
the same value that will be calculated and retired for the instruction at the head 
of RB. We formalize this by predicting the value of all instructions at dispatch 
time, and later prove that these predictions are correct. We can then assert that 

The predicted value of the head retirement buffer slot in des(b-|-1) 
equals that found in the the r’th register of the register file of des / (b-|- 1 ) , 
where r is the target index stored in the head slot of des(b-|-1). 

Similarly, dispatch buffer operand values which are now written back in system 
deS/(b-|-1) match the predicted values for these operands in system des(b-|-1). 

The final case is that of instructions which either generate interrupts or are 
mispredicted branches. We use predicted values to assert that when the slot at 
the head of the retirement buffer in des(b-|-1) is retired, an interrupt will be 
generated or a branch misprediction discovered. 

Once system des(b-|-1) retires the head slot all data structures of the two 
systems will again match. Until this retirement occurs, des(b-|-1) cannot is- 
sue another instruction (it has no free slots) but can execute and write-back 
instructions stored in the dispatch buffer. 



Values are predicted correctly In this subsection we sketch our proof that 
values are predicted correctly. 

We would like to prove that value finally obtained for a field matches its 
predicted value: 

■01 : Vs : [1..Z], j : [1..2]. DB[s\. oc f\ DB[s].arg[j].st ^ husy — > 
DB[s].arg[j].v = DB[s\.arg[j].pv 
A Wb : [I..B], RB ,rbe.[b].oc A ^RB ,rbe[b].busy — > 

RB.rbe[b].v = RB.rbe[b].pv A RB .rbe[b].int = RB .rbe[b].intpv 

The proof is inductive. The base case is the state before the start of execution. 
Since all dispatch and retirement slots are unoccupied property ipi holds trivially. 

Assume that ■0i holds at the current state. The next state is obtained by 
either issuing, executing, or retiring an instruction. These three cases are con- 
sidered separately. 

Consider a data instruction issued into dispatch buffer s and retirement buffer 
slot tail. The busy flag of retirement buffer slot tail is set to true, and thus there 
is no constraint on its predicted values. Each of the two operands Si of s are 
looked up in the RTT. If the RTT entry for Si is not busy, the value in RF[si] is 
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copied to both the value and predicted value fields of the dispatch buffer. Else, 
the status, value and predicted value fields are copied from the retirement buffer 
slot pointed to by the RTT. If the status of the retirement buffer slot is not 
busy then, by the induction hypothesis, its value and predicted values agree. 
Otherwise, the operand status is set to busy and there is no requirement that 
its value and predicted values agree. Thus, in all cases, if the operand status is 
not busy, its value and predicted value will agree. 

We next assume that instruction / is executed and written back. We consider 
first a data instruction. Both of its operands are available and are not busy and 
thus, by the induction hypothesis, their value and predicted value fields agree. 
The value of the instruction is calculated by applying the instruction operation 
to the value of the operands. As the predicted value was obtained by applying 
the operation to the predicted value of the operands, the value and predicted 
values for the instruction will agree. Thus, when the instruction value is written 
back to any operand fields waiting for it, and to the instruction retirement slot, 
it will match the predicted value field in these data structures. 

Interrupt generation and the predicted values of branches are both decided 
by the same functions, with the same parameters, as were used to predict the 
interrupt or the instruction value when the instruction was dispatched. This 
prediction is trivially correct. 

Lastly, we consider instruction retirement. The only value or predicted value 
fields modified are the value fields in the register file (which have no predicted 
values). It is easy to prove that ijji continues to hold. 

This completes the inductive step. This proof, like all others, has been rigor- 
ously proved in the PVS theorem prover. □ 



Completing the proof of refinement We would like to use the refinement 
rule of section 2. However, this rule requires that the abstract machine, progress 
one step with each step of the concrete machine, while we need the abstract 
system, deS/(b-|-1), to progress up to three steps with each step of des(b-|-1). 

To overcome this problem we follow Abadi and Lamport [1] in using auxiliary 
variables to introduce stuttering into the system. We add an auxiliary variable 
stutter to des(b-I-I) to derive system deSs(b-I-I). Intuitively, stutter is the 
minimum number of idling steps that the system must take before taking a 
non-idling step. When an instruction is dispatched into the B -|- I’st slot of 
des(b-I-I) stutter is set so as to force des(b-|-1) to idle while deS/(b-|-1) per- 
forms all the necessary actions to retire the head slot before dispatching the 
new instruction. The transition relation is modified so as to idle, decrementing 
stutter, if it is non-zero. 

The proof sketched above allows us to show that the stuttering system 
deSs(b-I-I) refines deS/(b-|-1). To complete the proof that des(b-|-1) refines 
deS/(b-|-1) we must show that des(b-|-1) refines deSs(b-I-I). 

Abadi and Lamport describe formally under which conditions a stuttering 
system refines a non-stuttering one. Our system fulfills these requirements and 
so des(b-I-I) refines deSs(b-I-I) and therefore des(b-|-1) refines deS/(b-|-1). 
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deS/(b+ 1) refines des(b): System deS/(b+1) has one more slot than des(b), 
but as it can never fill all its slots simultaneously, the two systems function as 
if they have the same number {B) of slots. The difference in the size of the 
buffer does, however, affect the values of the head and tail pointers - after the 
retirement buffer has wrapped these values no longer agree in the two systems. 
Similarly, any producer fields, whether in the dispatch buffer or register trans- 
lation table, do not agree for the two systems, and while each retirement buffer 
entry in system deS/(b-|-1) has a matching entry in des(b) its slot index differs. 

A mapping, map, is defined from slot indices in deS/(b-|-1) to those in 
des(b). The two systems are run in parallel, both issuing, executing and re- 
tiring instructions simultaneously. All data structures in the two systems are 
identical, modulo the map function. 

Refinement is thus intuitively simple: p\ is with the non-deterministic 
choices made as they were in system deS/(b-|-1). As our observation functions 
we take the register files of the two systems. Since the register files do not mention 
retirement slot indices, these are identical at all stages. 



7 Liveness Properties 

Our system is highly non-deterministic and each of the three sub-instructions 
(dispatch, execute or retire) can cause the system to idle instead of progressing. 
There is thus no guarantee that any instruction will ever complete. 

However, he have proved that it is always possible for the system to progress. 
That is, there is always at least one instruction in the system which can either 
be dispatched, executed or retired. 

8 Conclusion: Comparing the Two Proofs 

In this paper we have shown that both the direct, top-down approach, and an 
inductive methodology are applicable to proving the correctness of our specula- 
tive instruction execution model. We note that we used the top-down approach 
in proving invariants in the inductive proof, too. The two approaches are not 
mutually exclusive, however using induction modifies the structure of the proof 
enormously. In this section we compare the two approaches. 

We found that, perhaps counter-intuitively, the inductive proof was far more 
difficult to construct than the direct proof: it was far easier to prove refinement 
between a speculative and a sequential system than between two speculative 
systems where one has one more retirement buffer slot. 

Most of the complexity of the inductive proof was in proving that des / (b-|- 1 ) 
refines des(b-|-1). The data structures in the two systems are ‘almost’ the same, 
but we found it necessary to define precisely how they differ, in all circumstances. 
For example, the dispatch buffers are the same unless deS/(b-|-1) has retired one 
instruction more than des(b). In this case the dispatch buffer of deS/(b-|-1) will 
be empty if the retired instruction generated a flush. Otherwise, the value of the 
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retired instruction may be available in operand fields in deS/(b+1) but not in 
the corresponding fields in des(b+1). All the cases sketched in subsection 6.2 
had to be rigorously examined and formalized. The invariant a of the super- 
position system details the differences between each data structure of the two 
systems. 

In contrast, in the direct proof the comparison between the abstract and 
concrete systems involves only the observables, and the internal data structures 
(dispatch buffer, etc) of the speculative machine are not matched with any in the 
sequential system. The speculative system is designed so that externally its spec- 
ulative, out-of-order character is hidden and the register file presents an in-order 
view of instruction execution. Since we synchronize at retirement time we can 
compare the register files and not the internal data structures, utilizing the ex- 
ternal ‘in-order’ behavior of the speculative machine so that neither speculation 
nor out-of-order execution is overtly verified in the refinement proof. Instead, a 
number of extra invariants of the speculative system were needed to show that 
it, indeed, behaves ‘correctly’ - that instruction values are calculated correctly 
and that the correct instructions are flushed when mispredictions occur. In par- 
ticular, the instruction-operand relationship expressed by (/>2, ^3 and ^4 is used 
for the purpose of showing that instruction values are correctly calculated. These 
invariants have trivial counterparts in the base case of the inductive proof, and 
no counterparts in the inductive step. When we are performing a comparison 
between two speculative systems these properties hold in both systems and need 
not be expressed explicitly. 

Thus, the different structures of the two proofs resulted in different types of 
difficulty. In the direct proof the emphasis was on proving single system invari- 
ants, in the inductive proof on proving properties of the superposition system. 
While proving system invariants can be tedious and time consuming, it required 
less user effort than the complicated, if faster running, refinement analyses in 
the inductive proof. That single system invariants were easier to formulate than 
those of the superposition system is reasonable since the the relationship between 
two systems is potentially more complex than the complexity of each system in- 
dividually. Since human effort, rather than run-time, is the more limiting factor 
in deductive proofs of this type, we consider the slower, yet simpler, direct proof 
to be the more efficient and evaluate the top-down methodology as the one more 
appropriate for this problem. 

Our conclusion is that more important than the similarity of the systems 
between which we prove refinement is the complexity of the two systems and the 
granularity of the comparison between them. 

In the inductive proof both the abstract and concrete systems are of similar 
complexity; in the direct proof the abstract system is far simpler. The complexity 
of the abstract system contributes directly to the complexity of the refinement 
proof. Both the definition of the refinement relation and its proof are dependent 
on the complexity of both systems. For example, in proving premise R 1 of the 
refinement rule we generate for each concrete step a matching transition in the 
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abstract system. In the direct proof the simplicity of SEQ makes this trivial, in 
the inductive proof it is more difficult. 

The granularity of the comparison is crucial: When the comparison is fine 
grain it is reasonable that defining it correctly, and then proving it invariant, will 
be a process requiring a similarly detailed understanding of the systems. When 
the comparison is coarser much of the complexity is shifted from properties of the 
superposition system to properties of the individual systems, which, we believe, 
tend to be simpler to formalize. 

When using induction one compares two relatively similar systems. Intu- 
itively, this suggests that a fine grain comparison will often be necessary, as it 
is only in a detailed examination of the systems that a meaningful comparison 
can be made. The similarity of the systems seems to be, in this case, detrimen- 
tal rather than beneficent, implying both a complex abstract system and a fine 
grain comparison. 

The balance between the complexity of the additional single system invariants 
needed in a direct proof and the complexity of the inductive comparison will, 
of course, differ from problem to problem. However, it is our contention that 
not only was the inductive methodology inappropriate for our refinement, but 
that the difficulties we encountered will often occur when combining induction 
and refinement: Induction inherently suggests that the abstract system will be of 
complexity similar to that of the concrete system, with the differences between 
them small and thus apparent only in a fine grain comparison. 
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Abstract. In this paper we explore partial order reduction that make 
the task of verifying cryptographic protocols more efficient. These reduc- 
tion techniques have been implemented in our tool Brutus. Although 
we have implemented several reduction techniques in our tool Brutus, 
due to space restrictions in this paper we only focus on partial order re- 
ductions. Partial order reductions have proved very useful in the domain 
of model checking reactive systems. These reductions are not directly 
applicable in our context because of additional complications caused by 
tracking knowledge of various agents. We present partial order reductions 
in the context of verifying security protocols and prove their correctness. 
Experimental results showing the benefits of this reduction technique are 
also presented. 

Keywords: Model checking, partial order reductions, and security. 



1 Introduction 

Due to the rapid growth of such entities as “the Internet” and “the World Wide 
Web”, computer security has recently become a very popular topic. As more 
and more people gain access to these shared resources, and as more services are 
offered, the importance of being able to provide security guarantees becomes 
paramount. Typically, these guarantees are provided by means of security pro- 
tocols that make use of encryption. Several researchers have proposed techniques 
to analyze these protocols in an attempt to find errors or to prove them correct. 
There are three basic approaches for verifying such protocols. 

One of the first attempts at formalizing the notion of a correct protocol was 
the Logic of Authentication, more commonly known as the BAN logic [BAN90]. 
This logic proved useful in analyzing security protocols. Kindred and Wing 
helped to automate the use of this logic by developing a theory generator for 
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it [KW97]. However, one of the drawbacks of the logic is the lack of a formal 
model with which to define the semantics of the logic. 

There has been much work recently on formal models for security protocols. 
A number of researchers have used general purpose model checkers to verify 
authentication protocols [Low97,MMS97,Ros96]. In all these cases, the users 
must specify the “bad traces” and check to see if any of them are valid traces 
of the model. In [CJM98], we describe a special purpose model checking tool 
for verifying authentication protocols which has a built-in adversary that can 
construct new messages when trying to subvert a protocol. 

Bella and Paulson have used theorem proving to verify authentication proto- 
cols [BP97]. Their method requires that one express the set of all possible traces 
by providing a set of rules that describe how to extend a valid trace. Using the 
same syntax, one then describes the relationships between events that must hold 
true of correct traces, and Isabelle tries to prove that all valid traces are also 
correct traces. A theorem proving type approach is also taken by [Mea96]. 

Model checking based techniques for verifying security protocols suffer from 
the well known state explosion problem, i.e., the state space of the system grows 
exponentially in the number of components. In the domain of model checking 
of reactive systems there are numerous techniques for reducing the state space 
of the system. One such important technique is partial order reduction. This 
technique does not directly apply to our framework because we explicitly keep 
track of knowledge of various agents and because our logic can refer to this 
knowledge in a meaningful way. 

Partial order reduction allows one to prune the set of traces of a system 
by reducing the number of inter-leavings to be considered. For example, if the 
system is insensitive to permuting two actions a and /3, then one can consider 
only one interleaving (say a(3) and ignore the other interleaving (/3a) while 
exploring the system. This kind of reduction has proved valuable in verifying 
reactive systems [GPS96,Pel96,Val91]. In this paper we present partial order 
reduction technique as it applies to the verification of security protocols. The 
proof of correctness is also presented. Due to space limitations, proofs of various 
results are not presented, but the general structure of the proof of correctness 
is clearly described. The framework for our proof is fairly general so that other 
researchers working in this area can also use it. 

The rest of this paper is organized as follows: In Section 2 we review the 
most common way in which messages are modelled when verifying security pro- 
tocols. Sections 3 and 4 describe the computation model which we use to provide 
the semantics for the logic. This model is closely based on our tool, Brutus. 
The syntax and semantics of a logic capable of expressing properties of authen- 
tication and electronic commerce protocols are described in Section 5. Partial 
order reductions are described in Section 6. Experimental results are presented 
in Section 7. Related and future work are discussed in Sections 8 and 9. 
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2 Messages 

Typically, messages exchanged during the run of a protocol are constructed 
from smaller sub-messages using pairing and encryption. The smallest such sub- 
messages (i.e. those which contain no sub-messages themselves) are called atomic 
messages. There are four kinds of atomic messages. 

— Keys are used to encrypt messages. Keys have the property that every key k 
has an inverse k~^ such that for all messages m, {{m}k}k-^ = tn. (Note 
that for symmetric key cryptography the decryption key is the same as the 
encryption key, so k = k~^.) 

— Principal names are used to refer to the participants in a protocol. 

— Nonces can be thought of as randomly generated numbers. The intuition 
is that no one can predict the value of a nonce; therefore, any message 
containing a nonce can be assumed to have been generated after the nonce 
was generated. (It is not an “old” message.) 

— Data plays no role in how the protocol works but is intended to be commu- 
nicated between the principals. 

Let A denote the space of atomic messages. The set of all messages M. over 
some set of atomic messages A is inductively defined as follows: 

— li a & A then a G A 4 . (Any atomic message is a message.) 

— If mi € At and m2 G M then m\ ■ m2 G M. (Two messages can be paired 
together to form a new message.) 

— lim G M. and key k G A then {m}k G M. {A message m can be encrypted 
with key k to form a new message.) 

We would also like to generalize the notion of messages to message templates. 
A message template can be thought of as a message containing one or more 
message variables. To extend messages to message templates we add the following 
to the inductive definition of messages: 

— If w is a message variable, then v G Ai. 

Since all keys have inverses, we always take advantage of the following reduc- 
tion: {{m}fc}fe-i = m. It is also important to note that we make the following 
perfect encryption assumption: the only way to generate {m}k is from m and k. 
In other words, for all messages m,mi, and m2 and keys k, {m}k mi • m2, 
and {m}k = {m'}k' ^ m = m' A k = k'. 

We also need to consider how new messages can be created from already 
known messages by encryption, decryption, pairing (concatenation), and projec- 
tion. The following rules capture this relationship by defining how a message can 
be derived from some initial set of messages /. 

1 . li m G I then I \- m. 

2. If / h mi and I h m2 then I h m\ ■ m2, (pairing) 
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3. If / h mi • m 2 then I h mi and / h m 2 , (projection) 

4. If / h m and I \- k for key k, then / h {m}fe. (encryption) 

5. If / h {m}fe and / h then I \- m. (decryption) 

This defines the most common derivability relation used to model the capa- 
bilities of the adversary in the literature. Given some base set of messages /, we 
denote all the messages that can be derived from I as /, the closure of I under 
the rules above. For example, if Iq is some finite set of messages overheard by 
the adversary, then Iq represents the set of all messages known to the adversary. 
In general, / is infinite, but researchers have taken advantage of the fact that 
one need not actually compute /. Once we describe the semantics of our logic, 
it will be clear that it suffices to check whether m S / for some finite number 
of messages m. However, checking whether m € / must still be decidable. For a 
detailed discussion of this question, see [CJM98]. 

3 The Model 

We model a protocol by the asynchronous composition of a set of named commu- 
nicating processes which model the honest agents and the adversary. We would 
like to model an insecure and lossy communication medium, in which a principal 
has no guarantees about the origin of a message, and where the adversary is free 
to eavesdrop on all communications. Therefore, in the model, we insist that all 
communications go through the adversary. In other words, all messages sent are 
intercepted by the adversary and all messages received by honest agents are ac- 
tually sent by the adversary. In addition, in an attempt to subvert the protocol, 
the adversary is allowed to create new messages from the information it gains 
by eavesdropping. The adversary is also allowed to participate in the sessions as 
an honest agent. 

In order to make the model finite, we must place a bound on the number of 
sessions that a principal may attempt. A session will be modelled as an instance 
of a principals role in the protocol. Each session is a separate copy or execution 
of a principal and consists of a single sequence of actions that make up that 
agent’s role in the protocol, along with all the variable bindings and knowledge 
acquired during the execution An agent can have multiple sessions, but each 
session is executed once. When we combine these with a single session of the 
adversary, we get the entire model of the protocol. 

Each session of an honest principal is modelled as a 5-tuple {N, S,B, I, P) 
where: 

— N £ names is the name of the principal. 

— S' is the unique ID for this session. 

— B\ vars{N) — > A4 is a set of bindings for vars{N), the set of variables ap- 
pearing in principal N, which are bound for a particular session as it receives 
messages. 

^ Principal and agent will be used synonymously throughout the paper 
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— / C Af is the set of messages known to the principal of this session. 

— P is a process description (similar in style to CSP) given as a sequence of 
actions to be performed. These actions include the pre-defined actions send 
and receive, as well as user defined internal actions such as commit and 
debit. 

The model of the adversary, 17, is similar to that of an honest agent or 
principal; however, the adversary is not bound to follow the protocol and so 
it does not make sense to include either a sequence of actions Pq or a set of 
bindings Bq for the adversary. Instead, at any time, the adversary can receive 
any message or it can send any message it can generate from its set of known 
messages la- The global model is then simply the asynchronous composition of 
the models for each session, including the one corresponding to the adversary. 

4 Actions 

The actions allowed during the execution of a protocol include the two predefined 
actions send and receive as well as possibly some user defined actions. The 
model makes transitions between global states as a result of actions executed 
by the sessions. More formally, we define a transition relation ^ C 77 x 

5 X A X A4 X S where 77 is the set of global states, S again is the set of 

session IDs, A is the set of action names (which includes send and receive), 
and M is the set of all possible messages. We will use the notation a a' 
in place of (<j, s, a, m, cr') € ^ when it is more convenient. In the definitions 

below, we will denote the adversary’s session as 17 = {Nq, Sa, 4>, la,^) and the 
sessions corresponding to the honest agents as Pi = {Ni, Si, Bi, li, Pi) . We will 
use a = . . . ,Pn) to denote the global state before the transition and 

a' = (17', P'^) to denote the global state after the transition. In addition, 

we will use the notation B to denote the obvious extension of a set of bindings B 
from the domain of variables to the domain of message templates. In other words, 
B(m) is the result of substituting B(v) for every occurrence of v in the message 
template m for all the variables v appearing in m. 

s-send-m , 

— a — ^ a 

A session with ID s can send message m in global state cr and the new global 
state is a' if and only if 

1. I a' = /r? U TO. (The adversary adds to to the set of messages it knows.) 

2. There is a session Pi = {Ni, s, Bi, Ii,send{s-msg).Pl) in a such that in 

a', P[ = {Ni, s, Bi, li, P') and to = Bi{s-msg). (There is a session that is 

ready to send message to.) 

3. Pj = Pj for all j yf i. (All other sessions remain unchanged.) 

sreceive-m , 

~ a — ^ a 

A session with ID s can receive message to in global state cr and the new 
global state is tr' if and only if 

1. m G la- (The adversary can generate the message to.) 
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2. There is a session = {Ni, s, Bt, Ii,receive{r-msg).Pl) in a such that 

in cr', S'/ = {Ni, s, B[, P'), /' = liUm, and S' is the smallest extension 

of Bi such that B'i{r-msg) = m. (There is a session ready to receive a 
message of the form of m and its bindings are updated correctly in the 
next state.) 

3. 'Pj = Pj for all j yf i. (All other sessions remain unchanged.) 

s- Act ■m , 

— cr ^ a 

A session with ID s can perform some user defined internal action Act with 
argument to in global state a and the new global state is o' if and only if 

1. There is a session Pi = {Ni, s, Bi, li, Act{msg).Pl) in cr such that in a', 
P'i = {Ni,s,Bi,Ii,P{) and to = Bi{msg). (There is a session s that is 
ready to perform action Act with argument to.) 

2. Pj = Pj for all j yf i. (All other sessions remain unchanged). 

Notice that internal actions are purely symbolic, i.e., there is no semantics 
associated with these actions. 

Each possible execution of the model corresponds to a trace, a finite, alternating 
sequence of global states and actions tt = croaicria 2 • • • ctnUn for some n € N, 
such that (Ji_i ^ ai for 0 < i < n for the transition relation — > just defined. 
Actually, technically speaking ai belongs to the set S' x A x M, but abusing the 
notation slightly we will refer to ai as an action. 



5 Logic 

In order to specify the requirements or the desired properties of the protocol, we 
will use a first order logic where quantifiers range over the finite set of instances 
in a model. In addition, the logic will include the past-time modal operator 
so that we can talk about things that happened in the history of a particular 
protocol run or trace. The atomic propositions of the logic will allow us to refer 
to the bindings of variables in the model, to actions that occur during execution 
of the protocol, and to the knowledge of the different agents participating in 
the protocol. We will begin with the syntax of the logic, followed by the formal 
semantics. 



5.1 Syntax 

As stated above, we will use a first order logic where quantifiers range over the 
finite set of instances. The atomic propositions are used to characterize states, 
actions, and knowledge in the model. The arguments to the atomic propositions 
are terms expressing instances or messages. We begin by a formal description of 
terms. 

— If S is a instance ID, then S is an instance term. 

— If s is an instance variable, then s is an instance term. 
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— If M is a message, then M is a message term. 

— If m is a message variable, then m is a message term. 

— If s is an instance term, then pr(s) represents the principal that is executing 
instance s. 

— If s is an instance term and m is a message variable, then s.m is a message 
term representing the binding of m in the instance s. 

— If mi and m2 are message terms, then mi • m2 is a message term. 

— If mi and m2 are message terms, then {mi}m2 is a message term. Note that 
here we implicitly assume that m2 is of atomic type key. 

As in standard first order logic, atomic propositions are constructed from 
terms using relation symbols. The predefined relation symbols are “=” and 
“Knows”. The user can also define other relation symbols which would corre- 
spond to user defined actions in the model. The syntax for atomic propositions 
is as follows: (All relation symbols are used in the infix notation.) 

— If mi and m2 are message terms, then mi = m2 is an atomic proposition. 
Examples of this atomic proposition would be checking if a customer and 
merchant agree on the price of a purchase (Co .price = Mq. price), or to check 
if a particular instance of A believes it’s authenticating with B (Aq .partner 
= B). 

— If s is an instance term and m is a message term, then s Knows m is 
an atomic proposition which intuitively means that instance s knows the 
message m. This proposition can be used to check if the adversary has com- 
promised the session key (17 Knows K) 

— If s is an instance term, m is a message term, and Act is a user defined 
action, then s Act m is an atomic proposition which intuitively means that 
instance s performed action Act with message m as an argument. For ex- 
ample, this could be used to check if a customer Co has committed to a 
transaction with identifier TID (Cocommit TID). 

Finally, well-formed formulas (or wjfs for short) are built up from atomic 
propositions with the usual connectives from first-order and modal logic. 

— if / is an atomic proposition, then / is a wff. 

— if / is a wff, then ~^f is a wff. 

— if fi and /2 are wffs, then fi A /2 is a wff. 

— if / is a wff and s is an instance variable, then 3s./ is a wff. 

— if / is a wff, then Cpf is a wff. 

The formula 3s./ has the intent that there exists some instance sq such 
that / is true when you substitute sq for s in / while Cpf is supposed to mean 
that at some point in the past, / was true. We also use the following common 
shorthands: 



- /i V /2 = -'(-'/i A ^/2) 

- /l ^ /2 = ^/l V /2 
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“ /i ^ /2 = /i ^ /2 A /2 — > /i 

— Vs./ = -<3s.^f (For all instances, sq, / is true when you substitute sq for s.) 

— Dpf = -^Op^f (At all points in the past, / was true.) 

The formula Vs./ is supposed to mean that for any instance sq, / is true 
when you substitute sq for s in / while Dp/ is supposed to mean that at all 
points in the past, / was true. 

5.2 Semantics 

Next we provide semantics to the logic just presented. These semantics will be 
given in terms of the formal model presented in Section 3. Again, we begin with 
the terms of the logic. 

— An instance ID S refers to the instance with that ID. 

— An instance variable s ranges over all the instances corresponding to the 

honest agents in the model. 

— An atomic message M is an atomic message in the model. 

— A message variable v varies over messages in the model and can be defined 
as a binding variable in a particular principal. 

— The function pr maps an instance ID to a principal name. If s is an instance 

ID, then pr(s) is the principal executing the instance with ID s. 

— We use as a scoping operator. If s is an instance term and u is a mes- 

sage variable, then s.v refers to the variable v bound in the instance s. The 
interpretation a{s.v) of s.v in a particular state a is Bs(v), the value bound 
to the variable v in instance s in state cr. 

— Message terms can be concatenated using just as messages are concate- 
nated. 

— Similarly a message term mi can be encrypted with another message term m 2 
just as messages are encrypted in the model. 

The wffs of the logic will be interpreted over the traces of a particular model. 
Recall that a trace consists of a finite, alternating sequence of states and ac- 
tions 7T = aoaiai . . . cr„. Length of a trace tt is denoted by length{Tr). We give 
the semantics of wffs in our model via a recursive definition of the satisfaction 
relation \=. We will write (tt, i) \= f to mean that the i-th state in tt satisfies the 
formula /. We begin with atomic propositions. 

— (7T,z) 1= mi = m 2 iff tTi(mi) = (Ji{m 2 ). Thus the formula mi = m 2 is true 
in a state if the interpretations of mi and m 2 are equal. In other words, 
two message terms are equal in a state if after applying the appropriate 
substitutions to the variables appearing in the message terms, the resulting 
messages are equal. 

— The formula {tt,i) \= s Knows m iff Ui{m) S Ij for some instance Wj in 
such that Sj = s (the instance ID of is s). In other words, the formula 
s Knows m is true in a state if the instance with ID s can derive message m 
from its known set of messages in that state. 17 Knows m is true if the 
adversary Q knows message m (recall that 17 denotes the adversary). 
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— (tTjz) ^ s Act m for some user defined action Act iff cti = s • Act • m. In 
other words, the formula (s Act m) is true in a state if the transition taken 
to enter the current state was one in which instance s took action Act with 
argument m. 

The extension of the satisfaction relation to the logical connectives is the 
same as for standard first order logic. We use the notation /[sq\s] to denote the 
result of substituting every free occurrence of the instance variable s in / with 
the instance ID sq. 

— (tT,*) h iff (7T,t) ^ /. 

— (tt, i)\= /2 iff (tt, i) h h and (tt, i) |= /a 

— (ttA) 1= 3s. f iff there exists a honest instance sn in the model such that 
(7r,f) h f[so\s]. 

— (tt, i) 1= Opf iff there exists a 0 < j < * such that (tt, j) |= / In other words, 
the formula Op/ is true in a state of a trace tt if the formula / is true in 
any state of the trace up to and including the current state. 

A formula / is said to be true in a trace tt (denoted as tt |= /) iff / is true in 
every state of the trace tt. 



5.3 Specification Examples 

For the sake of concreteness, we now include examples of some of the properties 
we have checked using Brutus and how they are specified in our logic. For the 
sake of clarity, we break the specification into two parts. The first part (referred 
to as (/)p) expresses properties about honest agents. The second part (referred 
to as (j)o) pertains to the adversary. Hence, the entire specification is simply 
(f>H A 4>n- 

Payment Authorization. For the secure payment IKP protocol [BGH’’'95], we 
wish to show that whenever the customer’s account is debited, the customer 
must have authorized that debit. For this we simply choose (j)H to be 

VAq . (pr(Ao) = A) A (Aq debit (Aq.CC • Aq. price)) ^ 

3C'o.(pr(C'o) = C) A (Aq.CC = Cq.CC) A Op(C'o auth Ao.price) 

This formula states that for all sessions Aq, if Aq is a session being executed 

by the authority A, and Aq debits the credit card account Aq.CC by Aq. price, 
then there exists a session Cq being executed by the customer C with that same 
credit card number that authorized a debit of that amount. Since in this case 
we do not refer to the adversary, we let 4>q = true. 

Privacy. The IKP protocol should not reveal information about the transaction. 
In other words, only the appropriate principals should know the order informa- 
tion. For this we choose to be 
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VS'o .VCo . (pr(Co) = C) A {So Knows Cq.DESC) 

(pr(S'o) = C V pr{So) = M) 

This formula states that for all sessions So, if So knows the customer’s description 
{Cq.DESC) of the transaction, then So is a session being executed by either the 
customer or the merchant. We will also need to make sure that the adversary 
does not know the information, so we choose to be 

VCo • {pr{Co) = C) ^ -n{C Knows Cq.DESC) 

Non-repudiation. We may want to check that a principal cannot deny knowledge 
of a particular value (a key or nonce). For instance, in the Needham-Schroeder 
authentication protocol [NS78], we may want to make sure that whenever A 
ends a session with B, B must know the nonce created by A. Note, that this 
is a somewhat weak notion of non-repudiation. A may not be able to prove B's 
knowledge of ^’s nonce. Indeed, A may not even be able to convince itself that B 
knows the nonce. We are simply checking that there is no trace in which B does 
not know the nonce. For this specification we choose 4>h to be 

VS'o -VTo- So end pr{To) {Tq Knows Sq. N once) 

This formula states that for all pairs of sessions Sq and Tq, if So ends a session 
with To, then Tq knows the nonce generated by So. We choose (j)Q = true. 

5.4 An Ordering on Traces 

We introduce an ordering on traces that will aid us in proving the correctness of 
partial order reductions. Throughout this sub-section assume that we are given 
a specification </>. Since the number of sessions is finite, we can assume that the 
specification is quantifier free (see the equations given below). 

3s./ = V(Vi/[si\s] 

Vs./ = A(Vi/[si\s] 

In the equations given above we have assumed that there are n honest sessions 
with session IDs si, • • • , s„. We also assume that the negations are pushed down 
to the innermost level. A quantifier free formula where the negation has been 
pushed to the innermost level is said to be in negation normal form. Let APh be 
the set of atomic formulas corresponding to honest sessions that appear in the 
specification (see subsection 5.1). Similarly, let APq be the set of atomic formulas 
pertaining to the adversary that appear in the specification. A specification is 
called admissible if it is in negation normal form and the atomic formulas in 
APq appear negated. From here on, assume that formulas are constructed using 
the set of atomic formula APh U APq, and are admissible. We let CT he the 
class of normal and admissible formula built using the atomic formula in the set 

APh U APa . 
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Notice that the truth of a specification <f> on a trace tt is completely deter- 
mined by the values of the atomic propositions in the set APh and the adver- 
sary’s knowledge (the set of messages known to the adversary) at each state of 
the trace tt. Adversary’s knowledge determines the truth of the atomic formula in 
the set APq . Assume that for each state a we are given the set of atomic propo- 
sitions true in that state and the knowledge of the adversary. A(cr) C 2^^® is 
the labelling function which indicates whether an atomic proposition in APh is 
true in the state a or not (p G L{a) means that the atomic proposition p is true 
in the state a). Knowledge of the adversary in state a is denoted by In{cr), or 
equivalently the set of messages known to the adversary in the state cr is Io{a). 
We introduce a partial order between traces, which will help us to prove the 
correctness of our reduction techniques. 

Definition 1. A trace tti is greater than a trace tt2 (denoted by tti ^ tt2) iff 
there exists partitions {Ai, • • • , Am} and {Bi, • • • , Bm} of the two traces tti and 
7T2 such that the following conditions hold: 

— There exists 0 = oq < oi < «2 < • ■ ■ < am = lengthiiri) such that A^ = 
{(tti, Ofe-i -I- 1 ), • • • , (tti, flfc)}, or in other words Ak represents the sub-trace 
starting at index au-i + 1 and ending at a^. 

— A symmetric condition holds for the partition {i?i, • • • , Bm} of the trace 7T2 

with indices 0 = < 6i < 62 < • • • < 6m = length{'K2)- 

— For two states in the corresponding partitions Ak and Bk {1 < k < m) the la- 
belling of atomic propositions in APh is identical and adversary’s knowledge 
in every state of Ak is greater than in the last state of Bk ■ Since knowledge of 
the adversary is monotonic along a trace (adversary never forgets anything), 
this also implies that the adversary’s knowledge in an arbitrary state of Ak 
is more than the knowledge in all states of Bk- More precisely, the following 
conditions hold: 

Vs e AfeVs' e Bk{L{s) = L{s')) 
ys e Ak{In{s) 2 /fi((7T2,6fc))) 

Informally, the lemma given below states that if tti ^ 7T2 the correctness of 
an admissible specification in tti implies its correctness in tt2- 

Lemma 1. Given two traces tti, 7T2 such that tti ^ 7T2 and an admissible spec- 
ification (j), TTi \= (j) implies that 7T2 |= (/). In other words, the partial order ^ is 
monotonic with respect to the satisfaction relation |=. 



6 Partial Order Reduction 

Partial order reductions reduce the search space by ignoring redundant inter- 
leavings. The theory of partial order reductions is well developed in the context 
of verification of reactive systems [GPS96,Pcl96,Val91]. Reductions presented in 
this section are very heavily influenced by traditional partial order reduction 
techniques. However, since we are working with a very specific model and logic. 
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the theory is simplified and different. We present the theory as it applies to our 
setting. 

Throughout this section assume that we are given a specification (j) that is admis- 
sible. Recall that APh is the set of atomic propositions pertaining to the honest 
agents and APq is the set of atomic propositions referring to the adversary. An 
internal action Act is called invisible if and only if it does not appear in the 
specification (f>, or in other words Act is not referred to by the atomic formulas 
in the set APh- Next we describe transformations on traces. 

Permuting invisible internal actions (Rule 1) 

Consider a trace tt = croaiCTi . . . Un- If there exists a sequence of transitions 
aiai+iai+iai+ 2 , such that 0^+2 is an invisible internal action, and actions 
and «i +2 do not belong to the same session, then we can permute the actions to 
get a new trace given below: 



CToaiCTi . . . (TiQ;i+2Cr'i+iQ:i+i . . . CTn 



Permuting sends (Rule 2) 

This operation allows one to permute two consecutive send actions if they belong 
to different sessions. 

Moving send before receives (Rule 3) 

If a receive or an internal action Act appears before a send in a trace and 
these actions belong to different sessions, then this operation allows us to move 
the send action before the receive or the internal action Act. 

We call the set of transformations just described allowable operations on a trace. 
Suppose we obtain a trace tt' by applying one of the allowable operations to the 
trace tt, then we say that tt ^ tt'. The reflexive transitive closure of ^ is denoted 
by =>*. The following lemma is crucial in proving correctness of the partial order 
reduction. 

Lemma 2. Consider two traces tt and n' such that tt =k tt'. In this case tt < tt' . 

Using Lemmas 2 and 1, the proof of the following lemma is transparent (note 
that TT < tt'). 

Lemma 3. Assume that we are given a specification (f. If there are two traces 
TT and tt' such that tt =k* tt' , then tt' \= <f> implies that tt \= (jj, or equivalently 
TT ^ (j) implies that tt' ^ (j). 

The basic algorithm for verifying whether a protocol satisfies a specification 
works by exploring the state space starting from the initial state using depth-first 
search. As soon as we reach a state where the specification is false, we report an 
error. If the depth-first search procedure terminates without reporting an error, 
the protocol is correct. In the ensuing discussion we will focus on the depth-first 
search algorithm. In the description of the algorithms we do not show book- 
keeping details such as reporting an error or checking whether a state has been 
visited or not. Algorithm A given in Figure 1 performs the depth-first search 
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starting from state s. The predicate en(s,a) is true if action a is enabled in the 
state s, i.e., action a can be executed from the state s. The set of enabled actions 
EN{s) in a state s is { a | en(s, a) }. Algorithm A-po (shown in Figure 2) is the 
modified depth-first search procedure with partial-order reductions. The set of 
actions ample{EN{s)) is defined as follows: 

— If EN{s) contains an invisible internal action , then ample{EN{s)) is an 
arbitrary invisible action {Act} picked from EN{s). 

— Suppose EN(s) does not contain an invisible internal action, but does con- 
tain a send action. In this case ample{EN{s)) is an arbitrary send action 
picked from the set EN{s). 

— If EN{s) does not contain an invisible internal action or a send action, 
ample{EN{s)) is equal to EN{s) 

Theorem 1 proves the correctness of the partial order reduction. Notice that the 
reduced algorithm A-po explores fewer traces than the algorithm A. Theorem 1 
basically states that every trace considered by the exhaustive algorithm A can 
be transformed into a trace considered by the reduced algorithm Apo using 
allowable operations described earlier. 

1 funct dfs(s) 

2 EN (s} = { a I en{s, a) } 

3 foreach a € EN (s) 

4 dn dfs{a{s)) 

Fig. 1. Depth first search algorithm A 

1 funct dfs(s) 

2 EN (s} = { a I en{s, a) } 

3 foreach a G ample{EN{s)) 

4 do dfs{a{s)) 

Fig. 2. Modified depth first search algorithm Apo 

Theorem 1. For every trace tt considered by the algorithm A, algorithm Apo 
considers a trace tt' such that tt =>* tt'. 

Using this theorem along with other results proved earlier, subsequent discussion 
shows that the algorithm with partial order reduction will discover an incorrect 
trace if and only if the full algorithm A will discover an incorrect trace. Sup- 
pose the protocol we are verifying is incorrect. In this case algorithm A, being 
exhaustive in nature, will consider a trace tt such that n ^ (j)- Using Theorem 1 
we can deduce that the reduced algorithm Apo considers a trace tt' such that 
7T tt' . Using Lemma 3 we obtain that tt' ^ (p. Therefore, if the protocol is 

incorrect, the reduced algorithm will detect it. Since the reduced algorithm only 
executes a subset of actions enabled from a state, it only considers a subset of 
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the entire set of traces. This means that if the reduced algorithm finds an incor- 
rect trace, the protocol is incorrect. Hence the protocol is correct if and only the 
reduced algorithm A-po does not find an incorrect trace. Therefore, the reduced 
algorithm Apo can be safely used. 



7 Experimental Results 

The table shown in Figure 3 summarizes the results of applying partial reductions 
to a few protocols. We examined the IKP secure payment protocol [BGH+95], 
the Needham-Schroeder public key protocol [NS78], and the Wide-Mouthed Frog 
protocol [BAN90,Sch96]. Columns 2 and 3 give the number of initiator and re- 
sponder sessions used in the model. The other columns give the number of states 
encountered during state space traversal using exhaustive search and search with 
partial order reductions. The entries with an “X” represents computations that 
were aborted after a day of computation (over 700,000,000 states). 

Fig. 3. Table of results 



protocol 


init 


resp 


none 


partial order 


IKP 


1 


1 


17,905,267 


906,307 


N-S 


1 


1 


1,208 


146 


N-S 


1 


2 


1,227,415 


6,503 


WMF 


3 


3 


X 


1,286,074 



8 Related Work 

As mentioned in the introduction, there are several research efforts that have ap- 
plied existing model checkers to the verification of security protocols. Our model 
checker is especially built to check properties of cryptographic and electronic 
commerce protocols. For example, we explicitly keep track of the knowledge for 
each agent and our logic can refer to the knowledge of various agents. However, 
because we extend the system state to keep track of knowledge, the correctness of 
various reduction techniques in the domain of traditional model checking cannot 
be directly applied. Here we developed the theory of partial order reductions for 
the verification of cryptographic and electronic commerce protocols. A reduction 
similar to partial order reduction appears in [SS98] . In [SS98] authors use Mur^ 
to verify cryptographic protocols. The connection to partial order reductions 
was not made in [SS98] and the set of reductions considered in [SS98] are more 
restrictive than the ones considered here. Moreover, the arguments presented 
in [SS98] only apply to a restrictive logic. Arguments presented in this paper are 
much more precise and apply to a much richer logic. 
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9 Conclusion 

In this paper we presented a logic for specifying properties of security protocols. 
In this context, we also presented partial order reduction techniques. Experimen- 
tal results clearly indicate that this reduction technique significantly reduces the 
size of the state space. In the future, we want to test our ideas on larger proto- 
cols. Currently, internal actions do not have any semantics associated with them. 
In the future we also want to add semantics to internal actions, e.g., the debit 
action will actually debit the customer’s account. 
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Abstract. In this paper we show how model checking can be used for 
the verification of security protocols using a logic of belief. We model 
principals as processes able to have beliefs. The idea underlying the ap- 
proach is to treat separately the temporal evolution and the belief aspects 
of principals. Therefore, when we consider the temporal evolution, belief 
formulae are treated as atomic propositions; while the fact that princi- 
pal A has beliefs about another principal B is modeled as the fact that A 
has access to a representation of B as a process. As a motivating example, 
we use the framework proposed to formalize the Andrew protocol. 



1 Introduction 

In this paper we show how model checking (see, e.g., [5,6]) can be used for the 
verification of security protocols using a logic of belief (see [3] for an example 
of the use of a belief logic in security applications) . Our approach allows us to 
reuse with almost no variations all the technology and tools developed in model 
checking. 

Model checking allows us to verify concurrent reactive finite state processes. 
We model principals participating to a protocol session as (concurrent reactive 
finite state) processes able to have beliefs. The specification of a principal has 
therefore two orthogonal aspects: a temporal aspect and a belief aspect. The key 
idea underlying our approach is to keep these two aspects separated. In practice 
things work as follows: 

— when we consider the temporal evolution of a principal we treat belief atoms 
(namely, atomic formulae expressing belief) as atomic propositions. The fact 
that these formulae talk about beliefs is not taken into consideration. 

— We deal with beliefs as follows. The fact that principal oi has beliefs about 

another principal 02 is modeled as the fact that ai has access to a represen- 
tation of 02 as a process. Then, any time it needs to verify the truth value 
of some belief atom about 02, e.g., simply tests whether, e.g., 4 > 

holds in its (appropriate) representation of 02. Beliefs are essentially used 
to control the “jumping” among processes. This operation is iterated in the 
obvious way in case of nested beliefs. 
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The paper is structured as follows. In Section 2 we describe a well known 
protocol, the Andrew protocol, as a motivating example. Section 3 presents the 
theoretical framework we employ (called MultiAgent Finite State Machines). The 
description is given incrementally over the standard model checking notions. 
In particular, we adopt CTL [5] as the propositional temporal logic used to 
state temporal specifications. Section 4 shows how the Andrew protocol can be 
formalized in our framework. Section 5 describes the model checking procedure 
we propose, while Section 6 illustrates how the algorithm described in Section 5 
works in verifying a property of the Andrew protocol. Finally, some conclusions 
are drawn. 



2 The Andrew Protocol 

In this section we briefly recall a simple authentication protocol, known as the 
Andrew protocol, which has been proved to be vulnerable to various attacks (see, 
e.g., [3]). The protocol involves two principals, A and B, which share a secret 
key Kab, and carry out a handshake to authenticate each other. The ultimate 
goal of the protocol is to exchange a new secret session key AT'j, between A 
and B. B is intended to be the key server, while A is the recipient. 

We use standard notation, and present the version of the protocol proposed 
in [3] . Ni denotes a nonce (a fresh message) newly created by principal i for the 
current session; Kij is a shared key between principals i and j; {M^Ki, denotes 
a message M encrypted with the key Kij ; Mi , M 2 is the message resulting from 
the concatenation of the two messages Mi and M 2 ; while i ^ j : M denotes the 
fact that principal i sends the message M to principal j. The Andrew protocol 
can be formulated as follows: 



1 


A- 


^ B : 




2 


B 


: 


{Na, NbjKab 


3 


A- 


^ B : 


{^bjKab 


4 


B - 


: 


{K'„Ni}K^, 



Intuitively, the protocol works as follows: with message 1, A sends B the (fresh) 
nonce Na encrypted with the key Kab, which is supposed to be a good key. The 
goal of this message is to request authentication from B. With message 2, B 
sends back to A the nonce Na concatenated with a newly created nonce Nb, 
both encrypted. At this point, since B must have decrypted message 1 to be 
able to generate message 2, A knows that it is talking with B. Then, in message 

3, A sends back to B Nb encrypted. This allows B to conclude that it is actually 
talking to A (as it must have decrypted message 2 to obtain Nb and generate 
message 3). The two principals are now authenticated. Finally with message 

4, B sends A the new session key together with a new nonce encrypted 
with the shared key. The final message is the one subject to attacks. Indeed, 
in message 4 there is nothing that A can recognize as fresh. An intruder might 
send A an old message, possibly containing a compromised key. 
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The kind of analysis we’re interested in is based on the idea, originally pro- 
posed in [3] (but see also [1]), of studying how messages sent and received during 
a protocol session by a trusted party may affect its beliefs about the other par- 
ties. In the present case, one might want to prove the following property: after 
message 4 has been received by A (respectively B) believes that the new key 
is a good key between A and B. Another property is that after message 4, A 
(respectively B) believes that B (respectively A) believes that the new key is a 
good key for communication between A and B. As pointed out in [3], the second 
property is stronger than the first, as it ensures that both principals believe that 
the protocol ended correctly and that they both possess a good session key. It 
turns out that neither of the properties above can be attained by principal A. 



3 Multiagent Finite State Machines 

Principals engaged in an authentication session can be modeled as finite state 
processes. We build the notion of principal (agent) incrementally over the notion 
of process. Suppose we have a set I of principals. Each principal is seen as a 
process having beliefs about (itself and) other principals. We adopt the usual 
syntax for beliefs: Bi(() means that principal i believes (f>, and (/) is a belief of i. 
Bi is the belief operator for i. 

The idea is to associate to each (level of) nesting of belief operators a process 
evolving over time. Therefore, let B = {bi, ..., s„}, where each index 1, ..., n G I 
corresponds to a principal. The set B* denotes the set of finite strings of elements 
of B, i.e., strings of the form Bi, ..., b„ with b^ G B. We call any a G B* , a view. 
Each view in B* corresponds to a possible nesting of belief operators. We also 
allow for the empty string, e. Figure 1 depicts the general structure of the views. 
The intuition is that e represents the view of an external observer (e.g., the 
designer) which, from the outside, “sees” the behavior of the overall protocol. 
To each nesting of belief operators we associate a view of the corresponding 
principal. Intuitively, in Figure 1, the beliefs of principal 1 correspond to the 
view Bi and can be modeled by a process playing I’s role. The beliefs that 1 
has about (the behavior of) principal 2 correspond to the view B 1 B 2 and can be 
modeled by a process playing 2’s role in (I’s view of) the protocol. Things work 
in the same way for the beliefs of 2 and the beliefs that 2 can have about 1. 

We associate a language £a to each view a G B*. Intuitively, each £„ is the 
language used to express what is true (and false) of the process of view a. We 
employ the logic CTL, a well known propositional branching-time temporal logic 
widely used in formal verification [5]. For each a, let Pa be a set of propositional 
atoms. Each Pa allows for the definition of a different language, called a Multi- 
Agent Temporal Logic (MATE) language (on Pa). A MATE language Ca on Pa 
is the smallest CTL language containing the set of propositional atoms Pa and 
the belief atoms Bi4>, for any formula 4> of CaBi- In particular, is used to 
speak about the whole protocol. The language Csi is the language adopted to 
represent i's beliefs. The language CsiEj is used to specify i’s beliefs about j’s 
beliefs, and so on. For instance, the formula AG (p D Bi^q) G £e, (denoted by 
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e : AG {p D Bi^q)), intuitively means that in every future state, if p is true then 
principal i believes q is false. Given a family {Pa} of sets of propositional atoms, 
the family of MATL languages on {Pa} is the family of CTL languages {Ca}- 
We are interested in extending CTL model checking to the model checking 
of belief formulae. In model checking, finite state processes are modeled as finite 
state machines. A finite state machine (FSM) is a tuple / = (S', J, R, L), where S 
is a finite set of states, J C S is the set of initial states, the transition relation R 
is a total binary relation on S, and L : S ^ 'P(P) is a labelling function, which 
associates to each state s € S the set L{s) of propositional atoms true at s. 
Our solution is to extend the notion of FSM to that of MultiAgent Finite State 
Machine (MAFSM), where, roughly speaking, a MAFSM is a finite set of FSMs. 

A first step in this direction is to restrict ourselves to a finite number of 
views a. Let i?" denote a finite subset of B* obtained by taking the views in 
any finite subtree of B* rooted at e. This restriction is not enough, as a finite 
set of views still allows for an infinite number of belief atoms. Even if we had a 
finite number of processes we would not be able to model them as FSMs. This 
problem can be solved introducing the notion of explicit belief atoms as a finite 
subset of the set of belief atoms. Explicit belief atoms are the only belief atoms 
which are explicitly represented in a FSM. 

Formally, if £„ is a MATL language of view a, then for each belief operator 
Bi, the set Expl{Bi,a) of explicit belief atoms of Bi for a is a (possibly empty) 
finite subset of the belief atoms of We have the following: 

Definition 1. Let {Ca} be a family of MATL languages on {Pa}- A MultiAgent 
Finite State Machine (MAFSM) F = {Eq} for {Ca} is a recursive total function 
such that: 

L Fe ^ 0 ; 

2. for all views a € E” C B* with E” finite, it associates with a a finite set Fa 
of FSMs on the MATL language on the following atoms: Pa and , for every 
principal i, Fxpl{Bi,a); 

3. for all the views a £ B* \ E", Fa = 0 . 

where B* \ E” denotes the difference between B* and E”, namely the set of all 
views not contained in E”. 
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Fig. 2. Explicit belief atoms and satisfiability 



The first condition ensures that the protocol specification is not empty; the 
second allows us to deal, in each view, with finite sets of FSMs; and the third 
restricts us to a finite number of views. In general, there may be more than one 
FSM associated with each view. This allows for situations in which a view can 
be only partially specified, and consequently there can be more than one process 
modeling that view. If it is completely specified, a view contains only one FSM. 

Given the notion of MAFSM, the next step is to give a notion of satisfiability 
in a MAFSM. We start from the notion of satisfiability of CTL formulae in an 
FSM at a state (defined as in CTL structures). Since FSMs are built on the 
propositional and explicit belief atoms of a view, to assess satisfiability of the 
propositional and explicit belief atoms (and the CTL formulae build out of them) 
we do not need to use the machinery associated with belief operators. However, 
this machinery is needed in order to deal with the (infinite) number of belief 
atoms which are not memorized anywhere in MAFSM. 

Let Impl{Bi,a), the set of implicit belief atoms of a view a, be the (infi- 
nite) subset of all belief atoms of £q, which are not explicit belief atoms, i.e., 
Impl{Bi,a) = {Bi(j) € Ca \ Expl{Bi,a)}. The idea is to use the information ex- 
plicitly contained in the labelling function of each state s of a FSM / of a view 
a to assess the truth value of the implicit belief atoms at a state s. Figure 2 
illustrates the underlying intuition. Intuitively, the principal modeled by FSM / 
(in view a), when in state s, ascribes to principal i the explicit belief atoms of 
the form Bicj) true at s. This means that the FMSs of view aBi, which model 
the beliefs of i, must be in any of the states (s' and s" in Figure 2) in which the 
formulae (f>, occurring as arguments of the explicit belief atoms, are true. This 
motivates the following definition. Let ArgExpl{Bi,a,s) be defined as follows: 

ArgExpl{Bi,a, s) = {4> € CaBi \ Bicj) G L(s) n Expl(Bi, a)} 

ArgExpl(Bi, a, s) consists of all the formulae (p € CaBi such that the explicit 
belief atom Bip is true at state s (i.e., it belongs to the labelling function of s). 
The set ArgExpl(Bi,a, s) contains the formulae which identify the states in 
which the FSMs in view aBi can be, whenever the process in view a is in state s. 

We are now ready to define the notion of satisfiability of implicit belief atoms. 
Let Bif) be an implicit belief atom of a view a. For each state s of a FSM of 
a, we can compute ArgExpl{Bi,a, s). As shown in Figure 2, we just need to 
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check whether all the reachable states ^ of the FSMs of view aSi, which satisfy 
ArgExpl{Bi, a, s) (namely, the set {(p} in Figure 2), also satisfy the argument ip 
of the implicit belief atom. If this is the case, then s satisfies Bitp. 

Definition 2. (Satisfiability in a MAFSM) Let F be a MAFSM, a a view 
in B* , f = (S', J, R, L) € an FSM, and s G S a state. Then, for any formula 
(p of La, the satisfiability relation F,a,f,s \= (p is defined as follows: 

1. F,a, f,s\= p, where p is a propositional atom or an explicit belief atom: the 
same as FSM satisfiability; 

2. satisfiability of propositional connectives and CTL operators: the same as 
FSM satisfiability; 

3. F,a,f,s 1= Bitp, where Biip is an implicit belief atom, iff for all f € FaSi 
and s' reachable state of the FSM f , F,aBi,f',s' |= /\ArgExpl{Bi,a,s) 
D Ip. 

We have furthermore: 

4 . for every s G J, F,a, f \= cp iff F,a, f,s \= (p; 

5. F,a\= cp iff for all f G F^, F, a, / (= cp; 

6. F a: cp iff F,a\= cp. 

In the definition of satisfiability above. Item 3 is the crucial step. The formula 
/\ ArgExpl{Bi, a, s) is the conjunction of all the elements of ArgExpl{Bi, a, s).^ 
Item 4 states that a FSM satisfies a formula if this formula is satisfied in all its 
initial states. Item 5 states that a formula is satisfied in a view if it is satisfied 
by all the FSMs of that view. Finally, Item 6 states that a labeled formula a : cp 
is satisfied if cp is satisfied in the view corresponding to the label. 

4 Modeling the Andrew Protocol Using MAFSMs 

As described in Section 3, a MAFSM can be constructed out of the following 
elements: the structure of the views; the atomic propositions of each view and 
how they vary over time; the choice of explicit belief atoms of each view and 
how they vary over time; and the specification of the initial states for the FSMs 
in each view. In this section we present a MAFSM-based model of the Andrew 
protocol, thus providing, in turn, all these elements. For lack of space, we give 
only a partial description, emphasizing those elements of the model which are 
relevant to illustrate our approach. 

In the MAFSM modeling the Andrew protocol there is only one FSM per 
view. Indeed, the processes associated to the all the views can be completely 

^ A state s of a FSM is said to be reachable if there is a path leading from an initial 
state of the FSM to state s. 

^ Item 3 gives to belief operators the same strength as modal K(m), where m is the 
number of principals. In particular, we have that if F D </> is a theorem in a view 
then BiF 3 BiCp is a theorem in the (appropriate) view above, where BiF is the set 
{BiP \PgF}. 
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Fig. 3. The set of views of the Andrew protocol (Section 2) 

specified, starting from the protocol specification given in Section 2. In the pre- 
sentation below, we give the FSM specifications using the input language of the 
model checker NuSMV [4]. 

The structure of the views. The Andrew protocol involves two principals, A 
and B. Therefore, we have I = {A, Bj. We model each principal as having beliefs 
about the other. Since, for the sake of the example, we do not need to model 
beliefs that a principal has about itself, we will need only to consider, besides 
the external view e, the views of A and B, the view A has about B and the 
view B has about A. Therefore, i?” = {e, Ba,Bb, BaBb, BbBa}- Figure 3 shows 
the resulting situation, e (the external observer) is modeled as a process which 
“sees” all the messages sent and received by the principals. Ba and BbBa model 
the behavior of principal A, while views Bb and BaBb model the behavior of 
principal B. 



The set of atomic propositions Pa- In each view, we need to model a 
principal sending a message to another principal and/or receiving a message, 
as well as the properties the principal attributes to the (sub)messages it receives 
or sends. In particular, a (sub)message can be fresh and a key can be a good 
key for secret communication between the two principals. Each view has its own 
set of atomic propositions, reflecting the atomic properties of interest about its 
associated process. Since Ba and BbBa model the same principal, we associate 
to both of them the same set of atomic propositions. Similarly for the views Bb 
and BaBb- For what concerns the views Ba and BaBb in the Andrew protocol, 
we can consider the following set of atomic propositions: 



' send-B Na-Kab, 
rec Na-Nb-Kab, 



Pba = ' 



send-B Nb-Kab, 
recK,.N',.K,b. 

fresh Na, 

fresh K'^^.N[^.Kab, 

shk AT/j 






PbaBb 



' recNa-Kab, 
send A a-^b-h^ab^ 
send A K'^f,-NI^-Kab, 

< fresh Nb, > 

fresh K'^^.NI,.Kab, 

shk 



where the variables of the form rec M or send b M (where M is a message of 
the Andrew protocol) are called message variables and represent the act of re- 
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ceiving M, and sending M to B, respectively. For instance, rec Na-Nt-Kab and 
send,B Na-Kab in view Ba represent A receiving {Na, Nb}Kab (message 2 in the 
Andrew protocol), and A sending {Na}Kab B (message 3 in the Andrew 
protocol) , respectively. Variables of the form fresh M or shk M are called fresh- 
ness variables, and express freshness properties of (sub)messages. For instance, 
fresh Na in view Ba means that Na is a fresh (sub)message, while shk ex- 
presses the fact that AT'^ is a good shared key between A and B. For what 
concerns view e, we set: 

{ sends, A K'^b-^b-^ab, 
rec A K'^b-^'b-Kab, 

where the variables for the sent messages (e.g., sends , a Ar'j,_7V^_ATa{,) are labeled 
(in subscript) with both the sender (B) and the intended receiver (A), while 
those of received messages (e.g., recAK'^b-Nb-^ab) are labeled only with the 
actual receiver (A). With respect to the other views, the additional subscripts 
for both send and rec reflect the fact that e knows who sends a message to whom 
and who receives what message. 

Evolution of message variables. To specify the evolution of variables in a 
view we use the nextQ operator of the NuSMV input language. The next operator 
allows us to specify the next value of a variable in each state, possibly depending 
on its value in the current state. Since all variables are of type boolean, the 
possible values are T (for true) and F (for false). We report below the definitions 
of the next state value for some message variables in the language of view Ba, 
modeling the behavior of (the beliefs of) A. ^ 

Ba 

1 next(sendB Na-Kab) •'= case 

IsendB NaJKab : {T,F}; 

1 : sends Na-Kab; 
esac; 

2 next(recK'ab-N'b-Kab) := case 

sends NbJ<ab & IrecK'ab-K-Kab: {T,F}; 

1 : recK'ab-N'b-Kab; 
esac; 

Statement 1 contains a case statement, whose first clause {\sends Na-Kab '■ 
{T, F}) contains a precondition on the left-hand side and the next value on the 
right-hand side. The precondition is the negation of a message variable and is 
true when sends Na-Kab is false, that is if message Na-Kab has not been sent 
to B yet . The next value is a set of values ({T, F}). This intuitively means 
that the first message of the Andrew protocol ({A^ajifat) may or may not be 
sent (i.e., sends Na-Kab may nondeterministically take value T or F) in the 
next state, if it has not been sent yet in the current state. The second item is 
the “default” clause, and it is taken if the precondition in the first clause does 

® The label Ba at the top of a block of statements means that the block belongs to 
the specification of view Ba, and similarly for the other views. 
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not apply. The result of this clause is that sends N a-Kab keeps, in the next 
state, its current value. In Statement 2, the precondition of the first clause (i.e., 
sends N^-Kab & \rec K'^^^.Nl-Kab) is a conjunction of two boolean expressions. 
The first expression means that {Nt}Kab has been already sent to B, and the 
second means that has not been received yet. The next value again 

is the nondeterministic choice between values T and F (the message is received 
or not). The messages in each session of the Andrew protocol are supposed to 
be sent and received following the order reported in Section 2. Therefore, for 
each message variable, the preconditions in the next statement checks whether 
the previous message (and therefore all the previous messages) involving the 
current principal {A in the case of view Ba), has been already conveyed or not. 
The default clause is similar to that of Statement 1. The specification of the 
evolution of the other message variables in the other views is specified in a 
similar way. 

Evolution of freshness variables. In any path of states of a view, freshness 
variables for (sub)messages originated by that principal always keep their initial 
values. In the Andrew protocol, this is the case for Na in view Ba (and also 
BsBa)^ as expressed by the next statements below, and Nb in views Bs and 
BaBb- 
Ba 

3 next(freshNa) := fresh Na; 

Statement 3 simply says that fresh Na keeps the current value in the next state. 
Similar statements are made also for fresh Nb, fresh N^ and shk (which are 
messages originated by B) in the views modeling B. 

On the other hand, a principal can attain freshness of the messages it has not 
originated itself, only after it receives (possibly other) messages which contain 
them. Therefore, freshness variables of a message M not originated by a principal 
may change their value (e.g., from false to true) only when the principal has 
received a message containing M. After the last message of the session has 
been conveyed, the freshness variables of M keep their current value (no new 
information can be gained by the principal). Moreover, once it becomes true, 
a freshness variable remains stable. All of the above intuitions are specified as 
follows: 

Ba 

4 next(shkK'ab) •’= case 

IshkK'at, & !recK'a,.N',JKab : {T,F}; 

1 : shkK'ab ; 
esac; 

5 next(freshK'ai,-N'i,jKab) := case 

Fresh K'ab-N'b-Kab & hecKb-K-Kab : {T,F}; 

1 : fresh K'ab-N'b-Kab; 
esac; 

Statement 4 and 5 are very similar in form. As to statement 4, the 
precondition in the first clause of the case statement is a conjunction 
{IshkK'^i, & \rec K'^i^.NI^.Kab) of two negations (meaning respectively that 
is not known to be a good shared key”, and that the 
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been received yet”). If this condition is true, the nondeterministic choice on the 
left-hand side of the clause is taken. The “default” clause leaves the value of 
the variable in the next state unchanged. Statement 5 checks, in the first clause 
of the case statement, if the conjunction in the precondition {\ fresh 
& Irec K'^bJ^l^Kab) is true Nl}Kab is not known to be fresh, and it has 

not been received yet), and in this case chooses nondeterministically the next 
value of the variable. 

Clearly Statements 4 and 5 are very general and do not allow us to model 
appropriately the freshness of (sub)messages. Indeed, additional constraints are 
needed. Following the BAN logic approach, there are a number of properties of 
messages, which relate their freshness to that of their components. For instance, 
a principal can conclude that a message is fresh from the freshness of one of its 
components. This is the case for which is known to be fresh whenever 

Na is known to be."*^ NuSMV allows for specifying constraints on the admissi- 
ble (reachable) states by means of invariants, which are boolean formulae that 
must hold in every reachable state. The following invariant statement captures 
a relevant constraint on some freshness variables: 



Ba 

6 INVAR (fresh | fresh N'^) & rec Kb-K-Kab ^ fresh K^-K-Kab 

Invariant 6 is an equivalence (<-*■) whose left-hand side is a conjunction. The 
disjunction in the left conjunct (fresh AT'j, | fresh iV() means that AT'^ or iV( is 
fresh; the second conjunct is meant to be true when the message {K'^^,Nl^}Kab 
has been received. Intuitively, it states that A can consider (the encrypted mes- 
sage) fresh (right-hand side of the equivalence) if and only if it 

has received the message (second conjunct on the left-hand side) and either of 
its components is fresh (first conjunct on the left-hand side). Similar invariants 
must be added for each message received by the principal. 

View BaBb can be specified in a similar way. Some additional statements 
must be added, though, reflecting the role of principal B. Indeed, the Andrew 
protocol assumes that B is the key server (see Section 2). Therefore, B is sup- 
posed to generate and send a good shared key in message 4, whenever it believes 
that is fresh. Remember that we have a variable for the freshness 

of the last message of the protocol (namely, fresh K'^f^.NI^.Kab), and a variable 
for being a good key (shk Then we can specify the above invariant as 
an implication: 

BaBb 

7 INVAR fresh Kb-^'b-Kab shkK’^b 



^ For (sub)messages which are not originated by the principal, usually BAN-like log- 
ics substitute the notion of freshness with that of recentness. A message is then 
considered recently conveyed by another principal, if it is part of a fresh message 
encrypted with a secret key, shared with that principal. The difference between these 
two concepts is not relevant for the present paper. 
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Explicit belief atoms of a view. We need now to choose the explicit belief 



atoms of each view. In general, the choice of the appropriate set of explicit 
belief atoms of (the views in) a MAFSM depends on what kind of aspects of the 
protocol one wants to analyze, and on what kind of properties need to be verified. 
In the case of authentication protocols, principals can only gain information 
carried by the messages they receive. In BAN-like logics the freshness of the 
received messages is based on their form, and it is a basic property to be attained 
by a principal. We choose, therefore, the following belief atoms as explicit beliefs 
atoms: the beliefs about other principals having sent or received a given message, 
and the beliefs about the freshness of messages. In our case, we have: 



where, for instance, B Afresh N a in e intuitively means that A believes that Na 
is a fresh nonce; while BssendA in Ba expresses the fact that A 

believes that B believes that it has sent {AT';,, Nl^}Kab A. There are no explicit 
belief atoms in BbBa and BaBb, as they have no beliefs atoms at all in their 
language. Indeed, the example we are considering does not need to model more 
than two nesting of the belief operators. 

Evolution of explicit belief atoms. Variables representing explicit belief 
atoms are supposed to vary similarly to freshness variables. In particular, as long 
as there are still messages to be received by a principal of a view, explicit belief 
atoms of that view are free to change value from F to T. Once the last message of 
the protocol has been received, no new belief can be attained, and explicit belief 
atoms keep their value, thereafter. Again, once they become true, they remain 
stable. The following statement specifies how the value of BBsendA N a-Nb-Kab 
may vary in Ba'- 
Ba 

8 next(BBsendA Na-Nb-Kab) := case 

!BBsendANa-Nb.Kab & Irec Kb-K-^ab : {T,F}; 

1 : BBsendANaJSlb-Kab; 
esac; 

Very similar statements can be added for all the explicit beliefs in all views. 
Similarly to freshness variables, additional constraints, in the form of state invari- 
ants, on reachable states need to be added for explicit beliefs atoms. In particular 
we report below some relevant ones for the Andrew protocol. All these invariants 
can be seen as encodings of standard properties holding in BAN-like logics. 

Ba 

9 INVAR recKb-N'bJCab ^ BesendA Kb-N'b-Kab 
10 INVAR fresh Kb-N'b-Kab ^ B b fresh K^-N'b-Kab 

Both invariants are implications. Intuitively, Invariant 9 states that if it receives 
the message (left-had side of the implication) then A ascribes to B 

the belief that B has sent that message to A (right-hand side of the implication) . 
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Invariant 10 states that if it can conclude that Nl^}Kab i® fresh, then A also 
ascribes to B the same belief. 

Initial states of a view. Finally, we have to set the initial states of the FSM 
in each view. They can be specified as a boolean formula which identifies all and 
only the admissible initial states of the FSM. Following the BAN logic tradition, 
we want to model a single session of the Andrew protocol and study what beliefs 
each principal can attain at the end of the session. A protocol session starts with 
no message sent or received. Thus, the process in each view starts with the value 
of all the message variables set to false. Since no message has been received yet, 
freshness variables of messages not originated by a principal are set to false as 
well. All the other variables can take nondeterministically the value T or F in the 
initial states. The following specification in view Ba formalises these intuitions 
for the Andrew protocol: 

Ba 

INIT IsendB Na-Kab & 
hecNa-Nb-K^b & 

IsendB NbJKab & 

IrecKb-N'bJKab & 

IfreshKb-N’bJCab & 

IshkKU 

All the other views can be specified in a similar way. 



5 Model Checking a MAFSM 

The basic operation of a standard CTL model checking algorithm is to extend 
the labelling function of an FSM (which considers only propositional atoms) to 
all the sub-formulae of the formula being model checked. Let us call Extended 
FSM (or, simply, FSM when the context makes clear what we mean) the result 
of this operation. The generation of an extended FSM relies on the fact that the 
labelling function explicitly defines the truth value of all atoms. The problem is 
that in the FSMs of a MAFSM the labelling function is not defined on implicit 
belief atoms, whose truth value is therefore left undefined; and we need to know 
the truth values of the implicit belief atoms occurring in the formula to be model 
checked. The definition of satisfiability in a MAFSM (Item 3 in Definition 2) tells 
us how to solve this problem. 

The crucial observation is that ArgExpl(Bi, a, s), in Item 3 of Definition 2, 
is generated from the formulae in Expl (s^ , a) and the labelling functions of the 
FSMs in a; ArgExpl{Bi, a, s) is a finite set; and it only depends on the MAFSM 
specified (thus independent of the formula to be model checked) . For each belief 
operator Bi, Csi is called the (MAFSM) compatibility relation of and it is a 
relation defined as follows. Let exCExpl{Bi,a) be a subset of the explicit belief 
atoms of a view a. Then: 

„ . . f ( /’^ s') I G EaBi , s' a reachable state of f and 

^ ^ \ E,aB^,f,s \= {(j) \ Bi(j) G ex} 
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\^A 



Fig. 4. Some FSMs for the Andrew Protocol 



Starting from a view a and a subset of explicit belief atoms ex of a, ex) 

collects all the FSMs /' and reachable states s' of /' (in the view aBi) which 
satisfy the arguments of the explicit belief atoms ex (formally: {cj> \ Bi(f> S ex}). 
Intuitively, Csiict, ex) contains all the pairs (/',s') of view aBi, in which the 
process associated to view aBi can be, whenever the process modeling view a is 
in a state that satisfies all the explicit belief atoms in ex. 

It can be easily seen that, for /' a FSM of view aBi, s' any reachable state 
of /', and s a state of a FSM of view a: 

if,s') e CBi(a,L{s) r\ Expl{Bi,a)) iS F,aBi, f ,s' \= f\ArgExpl{B,,,a, s) 

where L{s)C\Expl{Bi, a) is the set of explicit belief atoms true at state s. Hence, 
the following holds: 

F,a, f,s\=Bi4> iff for all(/',s') G CBi(a,L{s) r\ Expl{B,,,a)), F,aBi, f , s' \=4> 

( 1 ) 

where Bi(j) is any implicit belief atom. 

Figure 4 represents the underlying intuition on the MAFSM for the Andrew 
protocol. The relation Cb^ {a, L{s)r\Expl{Bi, a)) is depicted as arrows connecting 
states of adjacent views. Let us consider view e. When the process associated to 
e is in state n, the external observer believes that principal A, modeled by view 
Ba, can be in any one of the states m and m! of the FSM of that view, which 
are compatible with state n. The states of view Ba are completely identified by 
the explicit beliefs of e true at state n. Therefore, e believes Bicp in state n if 
and only if each state of Ba, in which e believes A to be (i.e., states m and m! 
in Figure 4), satisfies (p. Given a state s' of a FSM /' of view aBi, we say 
that s' is compatible with a state s of a FSM of view a if the pair (/', s') belongs 
to CBi{a, L{s) n Expl{Bi, a)). 

The model checking algorithm MAMC— View(a, T) (see [2] for a complete 
description and a proof of correctness) takes two arguments: a view a, and a set 
of MATL formulae E C Ca. MAMC— View(o:, E) performs the following phases: 



532 Massimo Benerecetti and Fausto Giunchiglia 



Phase A. MAMC— View(o!, P) considers in turn the belief operators Bi. For 
each of them, the set Arglmpl^Bi, a, F), the set of all the formulae (j> which are 
arguments of the implicit belief atoms Bi<j) occurring in F , is computed. 

Phase B. MAMC— View(o;, F) calls itself recursively on the view below (e.g., 
aBi) and on the set ArgImpl{Bi, a, F). In this process, the algorithm recursively 
descends the tree structure which needs to be model checked. The leaves of this 
tree are the views for which there is no need to model check implicit belief atoms, 
as there are no more implicit belief atoms occuring in F. 

Phase C. This phase is a loop over all the FSMs / of the current view a to 
extend the labelling functions of the visited FSMs. This loop iteratively performs 
the following two phases: 

Phase C.l. In this phase, all the states of the FSM / of the current view a 
where the algorithm is, are labeled with the implicit belief atoms. This phase 
is executed only if there occur implicit belief atoms in the input formulae. The 
labelling of states of / is computed according to definition of satisfiability of im- 
plicit belief atoms in a MAFSM. Therefore, for each reachable state s of /, the set 
L(s)nExpl{Bi, a) is computed. Then, the algorithm computes the implicit belief 
atoms occurring in F which can be added to the labelling function of s. That is, 
for each implicit belief atom Bi4>, Bicj) is added to L{s) if (j) is satisfied by all the 
pairs (/', s') belonging to the compatibility relation Csi (a, L{s) n Expl{Bi, a)). 

Phase C.2. This phase simply calls a standard CTL model checking algorithm 
on the FSM / of the current view. Indeed, at this point every state s in the 
current FSM / is labeled (by phase C.l) with all the atoms (i.e, propositional 
atoms, explicit and implicit belief atoms) occurring in the input formulae. 

Notice that in phase C.2 we can employ any model checker (in our case 
NuSMV) as a black box. 

6 Model Checking the Andrew Protocol 

In this section, we show how the model checking algorithm described in Section 5 
works, trying to check a desired property of the Andrew protocol of Section 2. Let 
us consider the following property (from Section 2): A believes that B believes 
that K'^i^ is a good shared key, any time it receives the last message of the Andrew 
protocol. This property can be written as the following MATL formula in view e: 

e : AG {recA A Ba fresh Na ^ Ba Bb shk K'J (2) 

where the (sub)formula Ba Bb shk is an implicit belief atom. 

Phase A and B. We only have to consider the belief operator Ba- We con- 
struct the set ArgImpl{BB,e,F) = {Bb shk Since Bb shk K'^f^ is an im- 
plicit belief atom of e, MAMC— View(e, {AG (recA A B a fresh Na 

BaBb shk K'^if)}) calls itself recursively on view Ba and {Bb shk (call- 
ing MAMC— View(sA, {Bb shk In view Ba, we need to consider the 

operator Bb and to compute ArgImpl{BB, Ba, {Bb shk = {shkK'^^}. 
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MAMC— View(s^, {Bb shk descends to view BaBb (calling 

MAMC—View{B ABB,{shk K'^i^})). Phase B is not performed in view BaBb as 
no implicit beliefs occur in the input formulae (namely, {shk 

Phases C.l and C.2 at BaBb- The only formula to check in this view is the 
atomic formula shk The FSM of this view already contains the information 
about its truth value in each state (see Section 4). Therefore, both phases end 
immediately. 

Phase C.l at Ba- The FSM / of this view is labeled with the implicit 
belief atom Bb shk For each reachable state s of / and each 

pair if, s') G Cbb(ba, L{s) n ExpI{bb, Ba)), the intersection of 
Arglmpl^BB, Ba, {Bb shk = {shk AT'j,} and L{s') is computed. This gives 

either the empty set (meaning that shk is not true in s') or {shk itself 
(meaning that shk is true in s'). The final step consists in adding to L{s) the 
implicit belief atom Bb shk if every state of /', compatible with s, satisfies 
shk K'^^. It turns out that the states of Ba satisfying that implicit belief are those 
which satisfy rec K'^^.Nl^.Kab {A has received message 4) and fresh K at 

(message 4 is known by A to be fresh). All those states also satisfy the explicit 
belief atom Bb fresh (by Invariant 10), and are therefore compati- 

ble only with those states of view BaBb where fresh K'^i^.Nl^.Kab is true. Notice 
that there can be a reachable state of Ba where rec AT' and fresh Na are 
both true but fresh is false. This is possible, as nothing in message 4 

is recognisable by A as fresh. As a consequence, there is a reachable state of view 
Ba, which does not satisfy Bb fresh either. Let the state m of view 

Ba in Figure 4 be one such state. Therefore, state m satisfies rec K'^^.Nl^.Kab 
and fresh Na but not B b shk A'^j . 

Phase C.2 at view Ba- Once again, the formula to check is atomic (though 
an implicit belief atom). Therefore, this phase ends immediately. 

Phase C.l at e. We have now to process the implicit belief Ba Bb shk K'^^. 
It performs similar steps as in phase C.l for view Ba- It turns out that there 
is (at least) a reachable state in the FSM of e which does not satisfy this im- 
plicit belief. Indeed, as we have pointed out above, there is a state of view 
Ba (state m in Figure 4) which does not satisfy Bb shk K'^i^ but satisfies both 
fresh N a and rec K'^^.N{^.Kab- Let us assume that state n in e (see Figure 4) 
satisfies B a fresh N a and recAK'^b-Nb-Kab but does not satisfy the explicit be- 
lief atom Ba fresh K'^i^_N)^_Kab. n is actually a reachable state of the FSM of 
e. Since n satisfies recA K'^f^.NI^.Kab, by an invariant of e similar to Invari- 
ant 9, n also satisfies Ba recA K'ab-N'f^-Kab- Since n does not satisfy the belief 
atom Ba fresh K'^f^JA{^.Kab, the explicit belief atoms true at n are not enough 
to rule out the compatibility with state m in Ba (see again Figure 4). In- 
deed, m does not satisfy fresh therefore, it belongs to the com- 
patibility relation Cb^ L{n)C\Expl{B a, e)). State m, as we know, does not sat- 

isfy BBshkK'^^. As a consequence of (1), state n of e does not satisfy 
Ba Bb shk AT^j,. 
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Phase C.2 at e. Here the usual CTL model checking algorithm on the formula 
(2) is called. As expected, the final answer is negative since, from phase C.l 
in e, there are reachable states satisfying rec^ A B a fresh N a but 

not Ba Bb shk 

7 Conclusion 

In this paper we have described a model-checking based verification procedure 
for security protocols employing a logic of belief. Our approach allows us to reuse 
the technology and tools developed in model checking. 

To model beliefs in security protocols, we have defined the notion of Multi- 
agent Finite State Machine as an extension of the usual notion of Finite State 
Machine. Then, we have described a model checking algorithm which allows us 
to verify formulae containing belief (sub)formulae in a MAFSM. Finally, we have 
formalized within this framework a well known security protocol, the Andrew 
protocol. 
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Abstract. This paper describes an experience in formal specification 
and fault tolerant behavior validation of a railway critical system. The 
work, performed in the context of a real industrial project, had the follow- 
ing main targets: (a) to validate specific safety properties in the presence 
of byzantine system components or of some hardware temporary faults; 
(b) to design a formal model of a critical railway system at a right level 
of abstraction so that could be possible to verify certain safety properties 
and at the same time to use the model to simulate the system. For the 
model specification we used the Promela language, while the verifica- 
tion was performed using the Spin model checker. Safety properties were 
specified by means of both assertions and temporal logic formulae. To 
make the problem of validation tractable in the Spin environment, we 
used ad hoc abstraction techniques. 

Keywords: safety critical systems, formal verifications, fault tolerant 
behavior, linear temporal logic, model checking. 



1 Introduction 

In the area of industrial processes, the use of Formal Methods (FM) to check 
safety critical components is in evident increase. Due to the high integration 
of information technology in the quite total amount of control systems, safety 
request is becoming more and more pressing. However some other important 
factors induce industries to use FM. First of all, the interest in discovering as 
many errors as possible before entering in the production phase; in fact, during 
this stage the cost of correction per error increases enormously (see [16] for a good 
statistical study). Moreover, governments and international institutions require 
industries to conform to international standards (e.g., EN 50128 GENELEG 

* This work was supported in part by the CNR project “Strumenti Automatici per la 
Verifica Formale nel Progetto di Sistemi Software” 
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Railways Applications [20], or lEC 65108 [13]) where FM are strongly suggested 
for validation and verification analysis. 

In the last decade many industries, like the Ansaldobreda Segnalamento Fer- 
roviario, started pilot projects (e.g., the ones documented in [8,15,18,2]) directed 
to evaluate the impact of FM on their production costs. Within Ansaldobreda 
Segnalamento Ferroviario encouraging results [1,3] - using CCS process algebras, 
with properties expressed in CTL and verified in the JACK environment - have 
shown how, for railway control systems, could be possible to formalize significant 
models and to perform verification in the model checking [7,21,4] approaches. 
Similar studies, using different formalisms (e.g., [9] used VCL* and /rCRL to 
model a station vital processor and propositional logic to specify properties then 
verified in ASF+SDF), seem to confirm this positive trend. A recent thesis in [6], 
formally supports how railway systems share important robustness and locality 
properties, that distinguish them from most hardware systems and make them 
easily checkable in symbolic model checking and Stalmarck checking. 

In this paper we describe the principal results of a real project jointly car- 
ried out by Ansaldobreda Segnalamento Ferroviario and CNR Institutes - IFI, 
CNUCF and CPR - of Pisa. The project consisted in designing a formal model of 
a critical control system called Computerized Central Apparatus, and successively 
in verifying specific safety properties under the hypothesis of hyzantine faults. In 
this context, byzantine is to be intended as it was in Lamport et al. [14], where 
a byzantine component can arbitrarily fail in running its algorithm. In addition, 
other fault tolerant properties were verified under a weaker definition of byzan- 
tine fault, where a consistent behavior has been required. Industrial choices in 
Ansaldobreda suggested the use of the Promela [11] specification language, and 
of the Spin [12] model checker. 

The paper is organized as follows: in Section 2, we briefly and informally 
describe the system and all its component units; in Section 3 we recall the most 
important features of Promela and Spin; in Section 4 we explain the Promela 
specification used as formal model, and how we described, in Promela, com- 
munication time-out and byzantine behavior; in Section 5 we discuss some ab- 
straction and implementation techniques we used to contain the state explosion 
problem; in Section 6 we report some significant result of the verification phase, 
where a subtle and erroneous situation, due to the byzantine behavior of a mod- 
ule, was discovered; finally in Section 7 we conclude with some consideration on 
the whole experience. 



2 System Description 

The application we studied is a safety software within Safety Nucleus, which is 
part of a control system called Computerized Central Apparatus (ACC)^ pro- 
duced by Ansaldobreda Segnalamento Ferroviario [17]. The ACC is a highly 
programmable centralized control system for railway stations. It plays a critical 
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role in a wider railway signaling system, which is a very complex distributed ar- 
chitecture designed to manage a large railway network. Each node in the network 
is devoted to the control of a medium-large railway station, or a line section with 
small stations, or a complete low traffic line with a simple interlocking logic. 

The ACC architecture (see Figure 1) consists in two sub-systems that inde- 
pendently perform management and vital functions. Management functions. 




ACC 



Fig. 1. The Computerized Central Apparatus architecture and its environment 



run by a sub-section called Recording, Diagnosis and data Transmission (RDT), 
consists in auxiliary tasks, such as data recording, diagnostic management and 
remote control interface. Vital functions are reserved to control train move- 
ments and wayside equipment, and generally safe-critical procedures. This sec- 
tion of ACC is composed by a Safety Nucleus (SN), Peripheral Control Units 
(PCUs) and Control Posts (CPs). 

Due to the critical characteristic of the vital section of ACC, particular at- 
tention has been paid to design fault tolerant mechanisms aimed to avoid that 
non-predictable (temporary or permanent) faults might compromise the correct 
operation of the system. To guarantee a trustable level of robustness many com- 
ponents have been replicated and consistency control tests have been inserted 
into the algorithm defining the behavior of the system. The Safety Nucleus is 
specifically designed for these control and safety purposes. It is interposed be- 
tween CPs, from which an human operator can digit commands, and the PCUs 
that, in turn, execute them. Those commands are considered critical because 
their execution takes effect to critical machineries such as railway semaphores, 
rail points, or crossing levels. The SN has the principal aim to safely deliver 
the commands to the PCUs in case of faults in some hardware components. 
It is based on a triple modular redundancy configuration of computers which 
independently run different versions of the same application program. 

Peripheral Control Units are designed to execute critical operation and to 
directly command physical devices. Control Posts are formed by input/output 
interfaces and by terminal by with an human operator compose a request or a 
command. Control Posts will not be considered in this study. 
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3 PROMELA and SPIN 

Industrial choices within Ansaldobreda Segnalamento Ferroviario induced us to 
use Promela (Process Meta Language) [11] as specification language and Spin 
as model checker environments. The fact that Promela is an imperative lan- 
guage with variables, with a C-like syntax makes it quite appreciated in industrial 
environment: the use of C-|— I- is quite common in industrial development, and 
then with very low cost local engineers can learn Promela syntax and infor- 
mal semantics, so that they can use it as a formal interchange language in the 
model refinement step. In addition Promela is a language of general applica- 
bility introduced to describe distributed systems, communication protocols and, 
in general, asynchronous process systems and resorted to be quite appropriate 
for our project. 

For similar reasons Spin has been preferred. Spin can run on different plat- 
forms (Unix, Linux, Windows NT or Windows98), and this makes it possible, for 
the industries to have a closer control on the verification phase; for example by 
running some of the most significant test. In addition Spin performs on-the-fly 
analysis, and support several state compression strategies, quite useful in dealing 
with state explosion problems which usually arise in this kind of work. 

A Promela specification consists in one or more process templates (called 
also proctype) and in at least one process instantiation. The language is ex- 
tended with non-deterministic constructs and with communication primitives, 
send and receive^ using a weakly recalling Dijkstra’s guarded command lan- 
guage notation [5] and Hoare’s language CSP [10]. Processes can communicate 
via rendezvous, or via asynchronous message passing through buffered chan- 
nels or shared memory. In addition any running process can instantiate further 
asynchronous processes using process templates. 

Spin [12] is an efficient formal verification tool for checking the logical con- 
sistence of a specification given in Promela. Spin translates each Promela 
process template given in input, into a finite automaton. A global automaton of 
a system behavior is obtained by the interleaving product (referred as the space 
state) of all the automata of the processes composing the system. Spin accepts 
correctness claims specified either in the syntax of standard Linear Temporal 
Logic (LTL) [19], or as process invariants (using assertions) expressing base 
safety and liveness properties^. 

4 Formalization 

In this section we describe the Promela model of the vital section of ACC, and 
the Promela models used to formalize time-out expiring and byzantine faults^. 
We used four Promela processes for the SN, and a Promela process for each 

^ Further information about Promela and Spin can be found at the official Spin URL 
http : //plan9 .bell-labs . com/netlib/spin/whatispin.html. 

® The detailed specification is property of Ansaldobreda Segnalamento Ferroviario. We 
describe here, with permission, just what is needed to understand this work. 
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PCUs^. In the following with safety nucleus (lowercase) we mean the Promela 
model of the SN and with peripheral units (lowercase) the one of the PCUs. 



4.1 The Safety Nucleus Model 

A scheme of the safety nucleus processes and of the channels among them is 
reported in Figure 2. We want to underline: 

1. the three identical central processes, called module A, B, and C, implement- 
ing the triple modular redundancy; 

2. a special process called exclusion logic, devoted to checking the consistency 
of the three modules, and able to disconnect each of them if necessary; 

3. the interconnections among the modules, between the modules and the ex- 
clusion logic, and between the modules and the PCUs; 

4. the PCUs, here represented as a black box, composed by n control units. 




0 




Peripheral Oaitrol Itoits 

Fig. 2. The Promela processes with which we modeled the SN and the relative 
connections 



The modules A, B, and C are designed for: (a) collecting global information on 
the system state, composed by the local states of each modules, by the state of 
the peripheral units and busses; (b) performing local computation taking care of 
the information collected and composing commands to be sent to the peripheral 
units. The three modules can communicate each other via symmetric channels; 
each module is further connected, via symmetric channels, with the exclusion 
logic and, via a double bus, with the peripheral units. 

The behavior of a module is composed by a repeated sequence of phases, 
formally described with the following pseudo-code®: 

^ in the work we considered only two of such devices. 

® n is the number of peripheral units 
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loop 

1. * <synch.roiiization> 

2. <command elaboration> 

3. * <data exchange with the other modules> 

4. <distributed voting> 

5. * <communication to exclusion logic> 

{ communication with the PCUs } 

for i = 1 to n do 

6.1 if <is my turn> the 

6.2 * <synchronization> 

6.3 * <send command to the PCUs> 

6.4 * <receive acknowledge from the PCUs> 
endf or 

endloop 

During each phase a central module runs local computations or communicates 
with other components of the system (we have pointed out these phases with 
an *). In particular, in the synchronization phase each module sends to and 
receives (with time-out) from every other module a synchronization message. 
This phase is used to collect information about the activity state of the other 
modules: a time-out expiring is interpreted as a sign of the non activeness, and 
the module that caused the time-out will be excluded from any successively 
communication within the current loop. Because the system is expected to run 
at least 2 out of 3, if a module detect a time-out from all the other modules, then 
it commutes in a safe shutdown state. In the command elaboration phase each 
module performs local computations, and calculates commands to be sent to the 
PCUs. In the data exchange phase each module sends to and receives (with 
time-out) from every other module a message containing information about the 
local state of the other modules. In the distributed voting phase, each module 
checks the consistence of its local information with the one received from the 
other modules. In the communication with the exclusion logic, the result 
of this test is sent to the exclusion logic which, after having analyzed all the 
results, can disconnect a module considered potentially faulty. Successively, in 
the communication with the PCUs, a module communicates (with time-out) 
with the PCUs, following a particular circular protocol. At each loop only two 
modules are able to communicate their command to the PCUs: a distributed 
procedure assures a cyclic selection of the modules communicating with the 
periphery and a cyclic use of the busses, also in case of faults. 

4.2 The Peripheral Units Model 

A scheme of the peripheral units its processes and of the channels connecting 
them to the safety nucleus is reported in Figure 3. We can identify: 

• a process for each unit; 

• the interconnection (a double bus) between the units and each of the module 
of safety nucleus, here represented as a black box. 
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Fig. 3. The Promela processes with which we modeled the Peripheral Control 
Units and their connections with the safety nucleus 



In the real system each peripheral unit is composed by two computers in 
configuration 2 out-of 2, that we modeled by a single process. Its behavior can 
be summarized with the following pseudo-code: 

loop 

■[communication with the safety nucleus} 
parallel for i=l to 2 do 

<computer[i] receives a command from a module 
and sends acknowledgements in reply> 
endf or 
endloop 

Informally each computer waits for a command, and then returns an acknowl- 
edgement back to all the modules. 

4.3 Other Formalization Issues 

The Promela model given so far describes the correct behavior of the system, 
but to complete the specification phase we needed to formalize also: 

• a time-out expiring in the communications; 

• a byzantine behavior of a module of the system. 

• an arbitrary temporary fault in some system units. 

Time-Out Expiring. In the ACC most communications are with time-out. 
Since Promela does not deal with time, we had to abstract from any definition 
of it. To simulate a communication with time-out we defined a particular empty 
message, whose presence in a channel must be interpreted, by the receiver, as 
absence of any message it was waiting for, an than as a time-out expiring in a 
receive action®. In addition, wherever we had a send action we indeed introduced 

® Formally the empty message is defined as follows: supposing the type of a channel was 
the tuple (ti, t2, . . . tk), the empty message is the tuple (EMPTY)^ , where EMPTY 
is a specific non- null integer constant. 
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a non deterministic choice between either transmitting the “real” message or 
transmitting the empty message, as in the following Promela pseudo-code^: 

/* implementation of a send with time-out */ 
define EMPTY <value> 

chan c = [0] of <t>; // (synchronous) channel of type <t> 

<t> msg; // message of type <t> 

[. . .] 

if 

:: true -> c!msg // send the real message 

:: true -> c! EMPTY // send the empty message 

fi; 

Consequently a receive action needs to discern, depending on the content of the 
message, if a time-out has been expired or if the receiving has been successfully 
executed. Formally ®: 

/* implementation of a receive with time-out */ 
c?x -> 
if 

: : (x == EMPTY) -> <time-out failure> 

: : else -> <success> 

fi; 

Modeling a Byzantine Behavior. In order to model a situation in which the 
failure in one module of the safety nucleus, may cause conflicting information to 
be sent to the other modules, we need to develop a model of a byzantine behavior. 
In this context, byzantine behavior is to be intended as it was in Lamport et al. 
interpretation [14], and precisely: 

1. all loyal modules run the same algorithm, and in particular correctly send 
all messages as specified in the algorithm of Section 4.1 ; 

2. a byzantine module runs the same algorithm of a loyal module, but it can 
arbitrarily fail in executing it, and in particular it may send wrong messages, 
or send a message delayed respect to a synchronization, or send no message 
at all. 

In this interpretation of byzantine behavior, we have focused the attention on 
communication events. We have supposed that an arbitrary fault in the proce- 
dure will be visible, to the environment, only when the unit tries to communicate. 

^ We remind that in Promela, if : : guard i -> x : -.guard 2 -> y fi is a guarded 
non-deterministic choice between x and y, and c ! x is a send operation on the channel 
c, of the variable, or value, x. 

® We remind that, in Promela, c?x is a receive operation from the channel c, of a value 
locally memorized into the variable x. 
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A consequence of this assumption is that an arbitrary fault is modeled as a com- 
munication error, and precisely as either a communication of a corrupted mes- 
sage, or as a delayed communication, or as no communication at all. To generate 
corrupted messages, we have supposed to have a function corrupt{) : T — > T, 
for each message type T, used to compromise the contents of a message®. Then 
a byzantine behavior can be modeled as in the following Promela code: 



/* implementation of a send with byzantine failure */ 
define EMPTY <value> 
chan c = [0] of <t>; 

<t> msg; 



[. . .] 

if 

:: true -> c!msg // send the corrected message 

:: true -> clEMPTY // send the empty message (i.e., no messages) 

:: true -> c ! corrupt (msg) // send the corrupted message 



fi; 



Modeling a Temporary Faulty Component. Besides modeling a byzantine 
behavior of a central module, we were interested in some other arbitrary faults 
in: 

1. one or both busses connecting SN to PCUs; 

2. one or both computers of one or both peripheral units. 

In this case we were interested in formalizing faults that were persistent for 
at least one loop. This could be interpreted as a weaker byzantine behavior 
definition, in which we wanted to model an arbitrary fault in a component of 
the system, under the assumption that it behaves consistently (within a loop) 
when interacting with the other components. 

This weaker byzantine fault has been implemented as in the following pseudo- 
code, relative to the PCU formalization: 

loop 

0.1 <decide the state of each of the two busses> 

0.2 <decide the state of each of the two computers> 

{communication with the safety nucleus} 
parallel for i=l to 2 do 

® Possible instantiation for the corruptQ are: (a) if the type T is the boolean type, 
the not{) function; (b) if the type T is the integer type, supposing that EMPTY is 
a non-null integer value, the corruptQ function can be any integer valued function 
such that corrupt (n) = EMPTY iff n = EMPTY (to avoid semantic ambiguities 
from the EMPTY value and a corrupted message). 
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<computer[i] receives a command from a module 
[*] and EVENTUALLY sends acknowledgements in reply> 
endf or 
endloop 

With “decide the state” , we mean a preliminary setting of the functional state 
either of the busses or of the computers of the peripheral unit. In case of state 
“fault” every communication via the faulty bus or coming from the faulty com- 
puter, until the end of the loop, results in a time-out . 

5 Abstraction and Implementation Strategies 

The complexity of the model of ACC, more critic respect to state dimension 
than the other SN components, forced us to introduce modularity techniques to 
cope with the state explosion problem. We proceeded in the following ways: 

1. by fisically separating the implementation of each phase composing the ACC 
behavior, with the intention to use them as building blocks In other words 
we planned to develop the phases in separate files, to be included in main 
file representing the whole ACC model; 

2. by implementing each building block representing a communication phase, 
i.e. the ones where the three modules exchange a message, in a correct and 
in a hyzantine version; 

3. by implementing each building block representing a correct or a byzantine 
communication phase in a concrete and in an abstract version. 

In the byzantine (versus the correct) version, we modified communication 
primitives as described in Section 8. In this way we: (a) could take under control 
the state dimension growing of the whole model by inserting a byzantine phase, 
which introduces more non determinism than a correct phase, at a time; (b) 
could test the robustness of the system in presence of some particular byzantine 
phases and not in presence of a widely distributed, quite less realistic, byzantine 
behavior. 

In the concrete (versus the abstract) version, we modeled the communication 
without fixing, a priori, any ordering of the send/receive events. That is what 
happens in the real system. On the contrary, in the abstract version we impose 
a total order on those events. For example, we decided that the module A sends 
and receives first from B and then from C, that the module B first receives and 
sends to A and then sends and receives from C, and finally that the module C 
first receives from A and from B and then sends to A and to B. Note that the 
correct and the concrete, respect to the byzantine and the abstract implemen- 
tations, have different impact on the state space. In fact: (a) the correct version 
has less not determinism, as least in our implementation of byzantine communi- 
cation error; (b) forcing a total order on the send/receive eliminates all the non 
determinism in the external communication events. Inserting either the concrete 
or the abstract version of a particular phase in the whole model of ACC, we 
could obtain a set models of different abstraction level (see Figure 4). 
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While planning a modular model, we had tried to maintain an acceptable 
degree of scalability. In this case scalability is referred of abstract versus the 
concrete implementations and respect to certain properties decided in accor- 
dance with Ansaldobreda Segnalamento Ferroviario. Those properties express 
fundamental, known a priori, invariants on the communication phases among 
internal modules composing the ACC. Relatively to the local knowledge of each 
module, these properties can be informally described as: 

(PI) before starting a communication phase, at least two out of three modules 
are active; 

(P2) after a communication phase, each module has sent a message to all the 
other active modules; 

(P3) after a communication phase, in receiving from all the other active mod- 
ule, a module has either received a message, or detected a time-out ex- 
piring; 

(P4) after a communication phase, if a module has detect a time-out in receiv- 
ing from all the other active modules, it commutes in a safe shutdown 
state. 

Those properties, expressed as assertions on the code, was verified using the tool 
Spin, and resulted satisfied on both the concrete and abstract models. 




(B) 



Fig. 4. The framework in which we developed abstract/concrete and byzan- 
tine/correct model (A). An example of instantiation of the model (B) 



6 Formal Verification 

We checked safety properties by varying the number of the byzantine phases 
inserted in the model. In addition, whenever the state dimension started to 
become problematic for our computational resources, we preferred the abstract to 
the concrete implementation of some, or all, the phases. In this way we executed 
a wide set of verification runs. 
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In the following we list only some of the more significant properties checked 
and their formalization as LTL formulae: 

(FI) If two modules agree in recognizing something wrong in a third module, 
that module will be in the future disconnected. 

[] (pi -> □ (ql -> <> rl) ) 

In the previous formula pi stands for “the module A recognizes something wrong 
in C”, ql stands for “the module B recognizes something wrong in C” and rl 
“ C is disconnected” . 

(F2) When two or more modules are active, then a peripheral units is in a 
receiving state infinitely often and when it is in this state it effectively 
receives from two different modules. 

([] p2) -> ( ([] <> q2) M [] ( q2 -> (<> r2 M t2) ) ) 

In the previous formula p2 stands for “at least two modules are active” , q2 stands 
for “the peripheral unit is before the receiving phase” and r2 “the peripheral 
unit is after the receiving phase” and t2 “the senders of the two messages are 
different” . 

(F3) When two or more modules are active, if a peripheral units receives 
messages then it receives exactly two messages. 

( [] p3) -> [] ( q3 -> (r3 && t3) ) 

In the previous formula p3 stands for “at least two modules are active” , q3 stands 
for “the peripheral unit is before the receiving phase” and r3 “the peripheral 
unit is after the receiving phase (it has received two messages)” and t3 “it has 
received exactly two messages” . 

Interesting results were obtained in testing these properties on a model of the 
system with different communication phases affected by byzantine faults. The 
first and third properties resulted to be verified in the model with the byzan- 
tine faults in phases 1 to 5, while for the second SPIN reported an interesting 
counterexample in presence of byzantine faults in phase “communication with 
the periphery” . The counterexample showed how the byzantine module can ma- 
liciously induce the other two modules in erroneous deduction on the global 
state and consequently to wrongly execute the communication protocol with the 
peripheral control units. 

Most verifications, due to the high state space size required the use of both 
the two optimization strategies native in SPIN: the MA e COLLAPSE meth- 
ods, which respectively use a minimized version of the Biichi Automata and a 
compressed representation of the state vector. As an example we report in the 
following the Spin output relative to the verification to property (F2): 

for p.o. reduction to be valid the never claim must be stutter-closed 
(never claims generated from LTL formulae are stutter-closed) 
pan: acceptance cycle (at depth 2342) 
pan: wrote mainltl . c . trail 
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(Spin Version 3.2.3 — 1 August 1998) 
Warning: Search not completed 

+ Partial Order Reduction 
+ Compression 

+ Graph Encoding (-DMA=180) 
Full statespace search for: 



State-vector 196 byte, depth reached 2345, errors: 1 
990 states, stored 
699 states, matched 
1689 transitions (= stored+matched) 

256 atomic steps 
hash conflicts: 0 (resolved) 

(max size 2“19 states) 

7 Conclusions 

The project described in this paper consisted in verifying certain safety prop- 
erties on a model of a safety-critical control system in presence of byzantine 
behavior of one of its components. The real system has been validated also by 
Ansaldobreda Segnalamento Ferroviario, and errors we found confirmed the ones 
discovered with traditional techniques. The importance of developing a formal 
model, however stood in its great flexibility and in its high expandibility. In 
fact, during this project itself the model has been enriched, respect to the first 
requirements, or modified in some its procedures. 

On the basis of this project an assessment on the application of the tool we 
used to support formal specification and verification process has been done. For 
what concerns the language Promela, we already underlined its suitability and 
expressivity power in describing this type of distributed system. The only disad- 
vantage we found was the missing of any automatic management of termination 
of processes, that obliged us to model ad hoc time-out expiring as an active com- 
munication with heavy repercussion on the state dimension. In fact, we needed 
to explicitly formalize the shut-down behavior of a module as a module that does 
not anything but participating in all the communications by sending EMPTY 
messages to cause time-out. 

Regarding the tool Spin the most important fact to be underlined is related 
to strategies against the state explosion problem. In particular, the use of a 
minimized automaton encoding technique (MA) combined with the state com- 
pression option (COLLAPSE) resorted to be quite useful in helping with out-of 
memory problems, but at the cost of a very long execution time. 

As an example, in Figure 5 we have reported a quite significative represen- 
tative data, respect to all the other we obtained, concerning a verification run 
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on a 256 Mbyte RAM Pentium II - Linux Suse 5.3 - for a system model whose 
complete description required 348 bytes per state; in the figure memory and time 
resources have been compared using, respectively, the COLLAPSE (for which 
we had an out-of-memory termination, with the longest depth-first search path 
contained 15125 transitions from the initial state) and the COLLAPSE -|- MA 
options (for which we have successully terminated the verification, with longest 
depth-first search of 15916). 



Graficol 



Memory / Time Ratio 




COLLAPSE + MA 



Pagina 1 

Fig. 5. The Memory/Time ratio using collapse and graph encoding reducing 
memory techniques 
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